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Abstract 

Abstraction is one of the most promising approaches to improve the performance of problem 
solvers. In several domains abstraction by dropping sentences of a domain description - as 
used in most hierarchical planners - has proven useful. In this paper we present examples 
which illustrate signihcant drawbacks of abstraction by dropping sentences. To overcome 
these drawbacks, we propose a more general view of abstraction involving the change of 
representation language. We have developed a new abstraction methodology and a related 
sound and complete learning algorithm that allows the complete change of representation 
language of planning cases from concrete to abstract. However, to achieve a powerful 
change of the representation language, the abstract language itself as well as rules which 
describe admissible ways of abstracting states must be provided in the domain model. 
This new abstraction approach is the core of Paris (Plan Abstraction and Rehnement 
in an Integrated System), a system in which abstract planning cases are automatically 
learned from given concrete cases. An empirical study in the domain of process planning 
in mechanical engineering shows signihcant advantages of the proposed reasoning from 
abstract cases over classical hierarchical planning. 


1. Introduction 

Abstraction IS one of the most challenging and also promising approaches to improve complex 
problem solving and it is inspired by the "way humans seem to solve problems. At first, less 
relevant details of a given problem are ignored so that the abstracted problem can be 
solved more easily. Then, step by step, more details are added to the solution by taking an 
increasingly more detailed look at the problem. Thereby, the abstract solution constructed 
first is refined tovcards a concrete solution. One typical characteristic of most "work on 
hierarchical problem solving is that abstraction is mostly performed by dropping sentences 
of a domain description (Sacerdoti, 1974, 1977; Tenenberg, 1988; Unruh & Rosenbloom, 
1989; Yang & Tenenberg, 1990; Knoblock, 1989, 1994; Bacchus & Yang, 1994). A second 
common characteristic is that a hierarchical problem solver usually derives an abstract 
solution from scratch, "without using experience from previous problem solving episodes. 

Giunchiglia and Walsh (1992) have presented a comprehensive formal frame’work for 
abstraction and a comparison of the different abstraction approaches from theorem proving 
(Plaisted, 1981, 1986; Tenenberg, 1987), planning (Nevcell & Simon, 1972; Sacerdoti, 1974, 
1977; Tenenberg, 1988; Unruh & Rosenbloom, 1989; Yang & Tenenberg, 1990; Knoblock, 
1989, 1994), and model based diagnosis (Mozetic, 1990). For hierarchical planning, Korf’s 
model of abstraction in problem solving (Korf, 1987) allo’ws the analysis of reductions in 
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search caused by single and multiple levels of abstraction. He has shown that in the optimal 
case, abstraction can reduce the expected search time from exponential to linear. Knoblock 
has developed an approach to construct a hierarchy of abstraction spaces automatically 
from a given concrete-level problem solving domain (Knoblock, f990, f993, f994). These 
so called ordered monotonic abstraction hierarchies (Knoblock, Tenenberg, & Yang, f99fb) 
have proven useful in many domains. Recently, Bacchus and Yang (f994) presented an 
improved method for automatically generating abstraction hierarchies based on a more 
detailed model of search costs. 

All these abstraction methods, however, rely on abstraction by dropping sentences of 
the domain description which is a kind of homomorphic abstraction (Holte et ah, f994, 
f995). It has been shown that these kinds of abstractions are highly representation de¬ 
pendent (Holte et ah, 1994, 1995). For two classical planning domains, different “natural“ 
representations have been analyzed and it turns out that there are several representations 
for which the classical abstraction techniques do not lead to significantly improved problem 
solvers (Knoblock, 1994; Holte et ah, 1995). However, it is well known that normally many 
different representations of the same domain exist as already pointed out by Korf (1980), 
but up to now no theory of representation has been developed. In particular, there is no 
theory of representation for hierarchical problem solving with dropping sentences. 

From a knowledge-engineering perspective, many different aspects such as simplicity, 
understandability, and maintainability must be considered when developing a domain rep¬ 
resentation. Therefore, we assume that representations of domains are given by knowledge 
engineers and rely on representations which we consider most “natural” for certain kinds of 
problems. We will demonstrate two simple example problems and related representations, 
in which the usual use of abstraction in problem solving does not lead to any improvement. 
In the first example, no improvement can be achieved because abstraction is restricted to 
dropping sentences of a domain. In the second example, the abstract solution computed 
from scratch does not decompose the original problem and consequently does not cut down 
the search space at the next detailed level. We do not want to argue that the examples 
can never be represented in a way that standard hierarchical problem solving works well. 
However, we think it would require a large effort from a knowledge engineer to develop an 
appropriate representation and we believe that it is often impossible to develop a represen¬ 
tation which is appropriate from a knowledge-engineering perspective and which also allows 
efficient hierarchical problem solving based on dropping sentences. 

We take these observations as the motivation to develop a more general model of ab¬ 
straction in problem solving. As already pointed out by Michalski (1994), abstraction, in 
general, can be seen as switching to a completely new representation language in which the 
level of detail is reduced. In problem solving, such a new abstract representation language 
must consist of completely new sentences and operators and not only of a subset of the 
sentences and operators of the concrete language. To our knowledge, SiPE (Wilkins, 1988) 
is the only planning system which currently allows the change of representation language 
across different levels of abstraction. However, a general abstraction methodology which 
allows efficient algorithms for abstraction and refinement has not yet been developed. We 
want to propose a method of abstraction which allows the complete change of representa¬ 
tion language of a problem and a solution from concrete to abstract and vice versa, if the 
concrete and the abstract language are given. Additionally, we propose to use experience 
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from previously solved problems, usually available as a set of cases, to come to abstract 
solutions. The use of experience has already proven useful in various approaches to speed¬ 
up learning such as explanation-based learning (Mitchell, Keller, & Kedar-Cabelli, f986; 
DeJong & Mooney, f986; Rosenbloom & Laird, f986; Minton, f988; Minton, Carbonell, 
Knoblock, Kuokka, Etzioni, & Gil, f989; Shavlik & O’Rorke, f993; Etzioni, f993; Minton 
& Zweben, f993; Langley & Allen, f993; Kambhampati & Kedar, f994), and analogical or 
case-based reasoning (Carbonell, f986; Kambhampati & Hendler, f992; Veloso & Carbonell, 
f993; Veloso, f994). 

As the main contribution of this paper, we present an abstraction methodology and a 
related learning method in which beneficial abstract planning cases are automatically derived 
from given concrete cases. Based on a given concrete and abstract language, this learning 
approach allows the complete change of the representation of a case from the concrete to 
the abstract level. However, to achieve such an unconstrained kind of abstraction, the 
set of admissible abstractions must be implicitly predefined by a generic abstraction theory. 
Compared to approaches in which abstraction hierarchies are generated automatically, more 
effort is required to specify the abstract language, but we feel that this is a price we have 
to pay to make planning more tractable in certain situations. 

This approach is fully implemented in Paris (Plan Abstraction and Refinement in an 
Integrated System), a system in which abstract cases are learned and organized in a case 
base. During novel problem solving, this case-base is searched for a suitable abstract case 
which is further refined to a concrete solution to the current problem. 

The presentation of this approach is organized as follows. The next section presents an 
analysis of hierarchical problem solving in which the shortcomings of current approaches 
are illustrated by simple examples. Section three argues that a powerful case abstraction 
and refinement method can overcome the identified problems. Furthermore, we present the 
Paris approach informally, using a simple example. The next three sections of the paper 
formalize the general abstraction approach. After introducing the basic terminology. Sec¬ 
tion 5 defines a new formal model of case abstraction. Section 6 contains a very detailed 
description of a correct and complete learning algorithm for case abstraction. Section 7 
explains the refinement of cases for solving new problems. Section 8 gives a detailed de¬ 
scription of the domain of process planning in mechanical engineering for the production 
of rotary-symmetric workpieces on a lathe and demonstrates the proposed approach on ex¬ 
amples from this domain. Section 9 reports on a detailed experimental evaluation of Paris 
in the described domain. Finally, we discuss the presented approach in relation to similar 
work in the field. The appendix of the article contains the formal proofs of the properties 
of the abstraction approach and the related learning algorithm. Additionally, the detailed 
representation of the mechanical engineering domain used for the experimental evaluation 
is given in Online Appendix I. 

2. Analysis of Hierarchical Problem Solving 

The basic intuition behind abstraction is as follows. By first ignoring less relevant features 
of the problem description, abstraction allows problems to be solved in a coarse fashion with 
less effort. Then, the derived abstract (skeletal) solution serves as a problem decomposition 
for the original, more detailed problem. Korf (1987) has shown that hierarchical problem 
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solving can reduce the required search space significantly. Assume that a problem requires 
a solution of length n and furthermore assume that the average branching factor is b, 
i.e., the average number of states that can be reached from a given state by applying a 
single operator. The worst-case time complexity for finding the required solution by search 
is 0(5”). Now, suppose that the problem is decomposed by an abstract solution into 
k subproblems, each of which require a solution of length rii,... ,nk, respectively, with 
ni n 2 + ■ ■ ■ + Tik = n. In this situation, the worst-case time complexity for finding the 
complete solution is 0(5”^ + b''^^ + ■ ■ ■ + 5”'=) which is Please note that 

this a significant reduction in search time complexity. In particular, we can easily see that 
the reduction is maximal if all subproblems are of similar size, i.e., rai ~ ^2 ~ ~ 

However, to achieve a significant search reduction, the computed abstract solution must 
not only be a solution to the abstracted problem, it must additionally fulfill a certain 
requirement presupposed in the above analysis. The subproblems introduced by the abstract 
solution must be independent, i.e., each of them must be solvable without interaction with 
the other subproblems. This avoids backtracking between the solution of each subproblem 
and consequently cuts down the necessary overall search space. Even if this restriction is not 
completely fulfilled, i.e., backtracking is still required in a few cases, several empirical studies 
(especially Knoblock, 1991, 1993, 1994) have shown that abstraction can nevertheless lead 
to performance improvements. 

Unfortunately, there are also domains and representations of domains (Holte et ah, 1994, 
1995) in which the way abstraction is used in hierarchical problem solving cannot improve 
problem solving because the derived abstract solutions don’t fulfill the above mentioned 
requirement at all. In the following, we will show two examples of such domains which 
demonstrate two general drawbacks of hierarchical problem solving. Please note that in 
these examples, a particular representation is assumed. We feel that these representations 
are somehow “natural” and very likely to be used by a knowledge engineer developing a do¬ 
main. However, there might be other representations of these domains for which traditional 
hierarchical planning works. We assume that such representations are very difficult to find, 
especially if the domain representation should also fulfill additional knowledge-engineering 
requirements. 

2.1 Abstraction by Dropping Sentences 

In hierarchical problem solving, abstraction is mostly^ achieved by dropping sentences of 
the problem description from preconditions and/or effects of operators (Sacerdoti, 1974, 
1977; Tenenberg, 1988; Unruh & Rosenbloom, 1989; Yang & Tenenberg, 1990; Knoblock, 
1989, 1994). The assumption which justifies this kind of abstraction is that less relevant 
details of the problem description are expressed as isolated sentences in the representation 
which can be addressed after the more relevant sentences have been established. Ignoring 
such sentences is assumed to lead to an abstract solution useful to reduce the search at the 
more concrete planning levels. 

However, this assumption does not hold in all domains. For example, in many real world 
domains, certain events need to be counted, e.g., when transporting a certain number of 

1. Only Tenenberg’s (1988) abstraction by analogical mappings and the planning system SiPE (Wilkins, 

1988) contains first approaches that allow a change of representation language. 
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containers from one location to another. Imagine a domain in which, in addition to several 
other operators, there is an increment operator described as follows: 


Operator: inc 

Precondition: value(X) 
Delete: value (X) 

Add: value (X + 1) 


In this representation, the integer value which is increased is represented by a single sen¬ 
tence. Each state consists only of a single sentence, and also the operator contains only 
one single sentence.^ We think that this representation is very “natural” and very likely to 
be chosen by a knowledge engineer. In this domain, incrementing value(0) to value(8) 
requires a sequential plan composed of 8 inc-operators, leading to the state sequence: 
value(O) ,value(l),... ,value(8) . In this example, however, abstraction by dropping sen¬ 
tences does not work because, if this single sentence would be dropped, nothing would re¬ 
main in the operator description and the whole counting problem would have been dropped 
completely. So there is only the empty problem at the abstract level, and the empty plan is 
going to solve it. Unfortunately, the empty plan cannot cause any complexity reduction for 
solving the problem at the concrete level. Consequently, abstraction by dropping sentences 
completely fails to improve problem solving in this situation. 

However, we can adequately cope with this counting problem by abstracting the 
quantitative value expressed in the sentence towards a qualitative representation (e.g., 
low={0, 1, 2, 3}, medium = {4, 5, 6, 7}, high = {8,9,10,11}). Such a qualitative repre¬ 
sentation would result in an abstract plan composed of two operators (subproblems) that 
increase value from low to medium and further to high. This abstract plan defines two 
independently relinable subproblems. To solve the first subproblem at the concrete level, 
the problem solver has to search for a sequence of inc-operators which increment the value 
from 0 to any medium value (any value from the set {4, 5, 6, 7}). This subproblem can be 
solved by a sequence of 4 inc-operators leading to the concrete state with a value of 4. Sim¬ 
ilarly, the second subproblem at the concrete level is to find a sequence of operators which 
change the value from 4 to the final value 8. Also this second subproblem can be solved by 
a sequence of 4 inc-operators. So we can see that the complete problem which requires a 
sequence of 8 concrete operators is divided into 2 subproblems where each subproblem can 
be solved by a 4-step plan. Because of the exponential nature of the search space, the two 
4-step problems together can be solved with much less search than the 8-step problem as a 
whole. Following Korf’s analysis sketched before, the time complexity is reduced from 0(5®) 
to 0(5“^)®. Please note that the particular abstraction which leads to two subproblems is not 
central for achieving the complexity reduction. The important point is that the problem is 
decomposed into more than one subproblem. This kind of abstraction can be achieved by 
introducing a new abstract representation language which consists of the qualitative values 
and a corresponding abstract increment operator. 

2. However, we might assume that the term X -|- 1 is modeled as a separate predicate in the precondition. 

Unfortunately, this does not change the described situation at all. 

3. Because we assume many other operators besides the inc-operator, 6^1 holds. 
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We can even generalize from the specific example presented above. The problem with 
the dropping condition approach is that it is not possible to abstract information (e.g., 
the value in our example) that is coded in a single sentence in the representation. This is 
particularly a problem when the required solution contains a long sequence of states which 
only differ in a single sentence. Dropping this particular sentence leads to dropping the 
whole problem, and not dropping the sentence does not lead to any abstraction. What is 
really required is to abstract the information encoded in this single sentence which obviously 
requires more than just dropping the complete information. 

To summarize, we have seen that abstraction by dropping sentences does not work for 
the particular kind of problems we have shown. In general, abstraction requires chang¬ 
ing the complete representation language from concrete to abstract which usually involves 
the introduction of completely new abstract terms (sentences or operators). Within this 
general view, dropping sentences is just a special case of abstraction. The reason why drop¬ 
ping sentences has been widely used in hierarchical planning is that due to its simplicity, 
refinement is very easy because abstract states can directly be used as goals at the more 
detailed levels. Another very important property of abstraction by dropping sentences is 
that useful hierarchies of abstraction spaces can be constructed automatically from domain 
descriptions (Knoblock, 1990, 1993, 1994; Bacchus & Yang, 1994). 

2.2 Generating of Abstract Solntions from Scratch 

Another limiting factor of classical hierarchical problem solving can be the way abstract so¬ 
lutions are computed. As pointed out by Korf, a good abstract solution must lead to mostly 
independent subproblems of equal size. In classical problem solving, an abstract solution 
is found by breadth-first or depth-first search using linear (e.g., Alpine, Knoblock, 1993) 
or non-linear (e.g., Abtweak, Yang & Tenenberg, 1990) problem solvers. For these prob¬ 
lem solvers, the upward-solution property (Tenenberg, 1988) usually holds, which means 
that an abstract solution exists if a concrete-level solution exists. Usually, these problem 
solvers find an arbitrary abstract solution (e.g., the shortest possible solution). Unfortu¬ 
nately, there is no way to guarantee that the computed solutions are refinable and lead to 
mostly independent subproblems of sufficiently equal size, even if such a solution exists. 
In general, there are not even heuristics which try to guide problem solving towards the 
aspired kind of useful abstractions. This problem is illustrated by the following example, 
which additionally shows the limitation of abstraction by dropping sentences. 

Imagine a large (or even infinite) state space which includes at least the 8 distinct states 
shown on the left of Figure I. Each of these 8 states is described by the presence or absence of 
three sentences El, E2, and E3 in the state description. In the 3-bit-vector shown in Figure 
I, ”0” indicates the absence of the sentence and ”1” represents the presence of the sentence. 
The 8 different states described by these three sentences are arranged in a 3-dimensional 
cube, using one dimension for each sentence. The arrows in this diagram show possible state 
transitions by the available operators of the domain.'^ Each operator manipulates (adds or 
deletes) exactly one sentence of the state description, if certain conditions on the other 
sentences are fulfilled. The representation of two of these operators is shown on the right 

4. The dashed lines do not represent operators and are only introduced to make the shape of the cube more 
easy to see. 
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Figure 1: State space of an example domain and representation of two operators 


side of this figure. The subscript of the operator name relates to the respective transition 
in the state diagram. In general, we can see that 

• El can be manipulated, if and only if E2 0 E3 holds, 

• E2 can be manipulated, if and only if El = E3 holds, and 

• E3 can be manipulated, if and only if El V E2 holds. 

Furthermore, assume that there are many more operators which connect some other states 

of the domain, not shown in the diagram, to the 8 depicted states. Consequently, we 
must assume a branching factor of 5 ^ I at each state, which makes the search space for 
problem solving quite large. Besides the description of the domain. Figure I also shows 
three example problems: X —?■ X', Y ^ Y' and Z —?■ Z'. For example, the solution to the 
problem X —?■ X' is the 5-step path 000 —?■ 010 —?■ IIO —?■ Iff —?■ lOI —?■ 001. 

Now, let’s consider the abstract solutions which correspond to the concrete solutions for 
each of the three problems. For each problem, we want to examine the three possible ways of 
abstraction by dropping one of the sentences. For this purpose, the geometric arrangement 
of the states turns out to be very useful because abstraction can be simply viewed as 
projecting the 3-dimensional state space onto the plane defined by the sentences which are 
not dropped by abstraction. The left part of Figure 2 shows the three possible abstract 
state spaces which result from dropping one of the sentences. Here it is very important 
to see that in each abstract state space, every sentence can be modified unconditionally 
and independent of the other sentences. However, only one sentence can be modified by 
each operator. Thereby, all the constraints that exist at the concrete level are relaxed. 
The abstraction of the concrete solution to each of the three problems (X —?■ X', Y ^Y' 
and Z —7- X) with respect to the three possible ways of dropping conditions is shown on 
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Figure 2: Abstract state spaces by dropping conditions 


the right side of Figure 2. Each of the nine possible abstract solutions consists of three 
or four abstract operators. The sequence in which they have to be applied is indicated 
by the numbers which mark these operators. We can also see that whatever sentence we 
drop for any of the problems, an appropriate abstract solution exists which decomposes 
the original problem into independent refinable subproblems of sufficiently equal size. The 
main point about this example is that none of these abstract solutions will be found by a 
hierarchical problem solver! The reason for this is that for each of the abstracted problems 
there also exists a 0-step or a f-step solution in addition to the nine 3-step or 4-step solutions 
indicated by the depicted paths. However, such a short solution is completely useless for 
reducing the search at the next more concrete level because the original problem is not 
decomposed at all. The central problem with this is that most problem solvers will find 
the shorter but useless solutions first, and try to refine them. Consequently, the search 
space on the concrete level is not reduced so that no performance improvement is achieved 
at all. However, there might be other representations of this example domain in which a 
hierarchical problem solver comes to a useful abstract solution. We think, however, that 
the representation shown is quite natural because it represents the 8 different states with 
the minimal number of binary sentences. 

To summarize, we presented an example in which a useful abstract solution is not found 
by hierarchical planning although it exists. The reason for this is that planners usually try 
to find shortest solutions, which is a good strategy for the ground level, but which may 
not be appropriate at the abstract level. Neither it is desirable to search for the longest 
solutions because this might cause unnecessarily long concrete plans. 

3. Case Abstraction and Refinement 

As a way out of this problem, we propose to use experience given in the form of concrete 
planning cases and to abstract this experience for its reuse in new situations. Therefore, 
we need a powerful abstraction methodology which allows the introduction of a completely 
new abstract terminology at the abstract level. This makes it possible that useful abstract 
solutions can be expressed for domains in which abstraction by dropping conditions is not 
sufficient. In particular, this methodology must not only serve as a means to analyze 
different abstraction approaches, but it must allow efficient algorithms for abstracting and 
refining problems and solutions. 
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3.1 The Basic Idea 

We now introduce an approach which achieves case abstraction and refinement by changing 
the representation language. As a prerequisite, this approach requires that the abstract 
language itself (state description and operators) is given by a domain expert in addition to 
the concrete level description. We also require that a set of admissible ways of abstracting 
states is implicitly predefined by a generic abstraction theory. This is of course an additional 
knowledge engineering requirement, but we feel that this is a price we have to pay to 
enhance the power of hierarchical problem solving. Recent research on knowledge acquisition 
already describes approaches and tools for the acquisition of concrete level and abstract level 
operators in real-world domains (Schmidt & Zickwolff, 1992; Schmidt, 1994). An abstract 
language which is given by the user has the additional advantage that abstracted cases are 
expressed in a language with which the user is familiar. Consequently, understandability and 
explainability, which are always important issues when applying a system, can be achieved 
more easily. 

As a source for learning, we assume a set of concrete planning cases, each of which 
consists of a problem statement together with a related solution. As is the case in Prodigy 
(Minton et ah, 1989), we only consider sequential plans, i.e., plans with totally ordered 
operators. The planning cases we assume do not include a problem solving trace as for ex¬ 
ample the problem solving cases m Prodigy/Analogy (Veloso, 1992; Veloso & Carbonell, 
1993; Veloso, 1994). In real-world applications, a domain expert’s solutions to previous 
problems are usually recorded in a company’s filing cabinet or database. These cases can 
be seen as a collection of the company’s experience, from which we want to draw power. 

During a learning phase, a set of abstract planning cases is generated from each available 
concrete case. An abstract planning case consists of an abstracted problem description 
together with an abstracted solution. The case abstraction procedure guarantees that the 
abstract solution contained in an abstract case can always be refined to become a solution 
of the concrete problem contained in the concrete case that became abstracted. Different 
abstract cases may be situated at different levels of abstraction or may be abstractions 
according to different abstraction aspects. Different abstract cases can be of different utility 
and can reduce the search space at the concrete level in different ways. It can also happen 
that several concrete cases share the same abstraction. The set of all abstract planning cases 
that are learned is organized in a case-base for efficient retrieval during problem solving. 

During the problem solving phase, this case base is searched until an abstract case is 
found which can be applied to the current problem in hand. An abstract case is applicable 
to the current problem if the abstracted problem contained in the abstract planning case 
is an abstraction of the current problem. However, we cannot guarantee that an abstract 
solution contained in a selected abstract case can really be refined to become a solution to 
the current problem. It is at least known that each abstract solution from the case base 
was already useful for solving one or more previous problems, i.e., the problems contained 
in those concrete cases from which the abstract case was learned. Since the new problem is 
similar to these previous problems because both can be abstracted in the same way, there is 
at least a high chance that the abstract solution is also useful for solving the new problem. 
When the new problem is solved by refinement a new concrete case arises which can be 
used for further learning. 
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Figure 3: The components of the Paris System 


3.2 The PARIS Architecture 

Paris (Plan Abstraction and Refinement in an Integrated System) follows the basic ap¬ 
proach just described. Figure 3 shows an overview of the whole system and its components. 
Besides case abstraction and refinement, Paris also includes an explanation-based approach 
for generalizing cases during learning and for specializing them during problem solving. Fur¬ 
thermore, the system also includes additional mechanisms for evaluating different abstract 
cases and generalizations derived by the explanation-based component. This evaluation 
component measures the reduction in search time caused by each abstract plan when solv¬ 
ing those concrete problems from the case base for which the abstract plan is applicable. 
Based on this evaluation, several different indexing and retrieval mechanisms have been de¬ 
veloped. In these retrieval procedures those abstract cases are preferred which have caused 
the most reduction in search during previous problem solving episodes. In particular, ab¬ 
stract cases which turn out to be useless for many concrete problems may even become 
completely removed from the case-base. The spectrum of developed retrieval approaches 
ranges from simple sequential search, via hierarchical clustering up to a sophisticated ap¬ 
proach for balancing a hierarchy of abstract cases according to the statistical distribution of 
the cases within the problem space and their evaluated utility. More details on the gener¬ 
alization procedure can be found in (Bergmann, 1992a), while the evaluation and retrieval 
mechanisms are reported in (Bergmann & Wilke, 1994; Wilke, 1994). The whole multi¬ 
strategy system including the various interactions of the described components will be the 
topic of a forthcoming article, while first ideas can already be found in (Bergmann, 1992b, 
1993). However, as the target of this paper we will concentrate on the core of Paris, namely 
the approach to abstraction and refinement. 
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Figure 4: An example of case abstraction 


3.3 Informal Description of the Abstraction Approach 

We first give an informal description of the abstraction approach in Paris, based on our 
small example shown in Figure 1 to enhance the understanding of the subsequent formal 
sections. Suppose that the solution to the problem A —?■ A' is available as a concrete prob¬ 
lem solving experience. The task is now to learn an abstract case which can be beneficially 
used to solve future problems such as A Y' and Z —?■ Z'. This learning task must be 
achieved within an abstraction approach which is stronger than dropping sentences. If we 
look at Figure 4, it becomes obvious that by changing the representation a single abstract 
case can be learned which is useful for all three concrete problems. The abstract plan shown 
indicates which concrete states have to be abstracted towards a single abstract state, such 
that a single abstract plan exists which is useful for all three problems. 

3.3.1 Abstract Language and Generic Abstraction Theory 

To achieve this kind of abstraction, our approach requires that the abstract language (states 
and operators), as well as a generic abstraction theory is provided by the user. For the exam¬ 
ple in Figure 4, the abstract language must contain the new abstract sentences Ai,... , A 4 
and the three abstract operators which allow the respective state transitions. These abstract 
operators, called Oai (i G {1,... , 3}), can be defined as follows: 


Operator: Oai 
Precondition: Ai 
Delete: Ai 
Add: Aj_|_i 


For each new abstract sentence, the user must provide a set of generic abstraction rules 
which describe how this sentence is defined in terms of the available sentences of the con- 
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Crete language. The generic abstraction theory defined by these rules specifies a set of 
admissible state abstractions. For our example, the generic abstraction theory must con¬ 
tain the following two rules to define the new abstract sentence Ai: ^E1 A E2 —?■ Ai and 
^E1 A -i£’2 A -lifS — 7 - Ti. In general, the definition of the generic abstraction theory does 
not require that all state abstractions are noted explicitly. Abstract states can be derived 
implicitly by the application of a combination of several rules from the generic abstraction 
theory. 

Besides the kind of abstraction described above, the user may also want to specify 
a different type of abstraction which she/he also considers useful. For example, we can 
assume that abstraction by dropping the sentence El should also be realized. In this case, 
the abstract language must contain a copy of the two sentences which are not dropped, i.e., 
the sentences E2 and E3. Therefore, the user® may define two abstract sentences A 5 and 
Aq by the following rules of the generic abstraction theory: E2 —?■ A 5 and E3 Aq. Of 
course, the respective abstract operators must also be specified. 

Since the domain expert or knowledge engineer must provide the abstract language and 
the generic abstraction theory, she/he must already have one or more particular kinds of 
abstraction in mind. She/he must know what kind of details can be omitted when solving 
a problem in an abstract fashion. With our approach, the knowledge-engineer is given the 
power to express the kind of abstraction she/he considers useful. 

3.3.2 Model of Case Abstraction 

Based on the given abstract language and the generic abstraction theory, the abstraction of 
a planning case can be formally described by two abstraction mappings: a state abstraction 
mapping and a sequence abstraction mapping. These two mappings describe two dimensions 
for reducing the level of detail in a case. The state abstraction mapping reduces the level 
of detail of a state description while changing the representation language. For the case 
abstraction indicated in Figure 4, the state abstraction mapping must map the concrete 
states 000, Off and 010 onto an abstract state described by the new sentence Ai, and 
simultaneously it must map all other concrete states occurring in the plan onto the respective 
abstract states described by the new sentences A 2 , A 3 , and A 4 . The sequence abstraction 
mapping reduces the level of detail in the number of states which are considered at the 
abstract level by relating some of the concrete states from the concrete case to abstract 
states of the abstract case. While some of the concrete states can be skipped, each abstract 
state must result from a particular concrete state. For example, in Figure 4, the abstraction 
of the plan 000 —?■ 010 —?■ IIO —?■ Iff —?■ lOI —?■ 001 requires a sequence abstraction mapping 
which relates the first abstract state described by Ai to the first concrete state 000 , the 
second abstract state described by A 2 to the third concrete state IIO, and so forth. In this 
example, the second and the fifth concrete states are skipped. 

3.3.3 Learning Abstract Planning Cases 

The procedure for learning such abstract planning cases from a given concrete planning case 
is decomposed into four separate phases. For our simple example, these phases are shown in 

5. Please note that for abstraction by dropping sentences, we can also consider an ALPlNE-like algorithm 

which generates the required abstract language and the generic abstraction theory automatically. 
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Figure 5: The four phases of case abstraction for the solution to the problem X ^ X' 


Figure 5. In phase-I, the states which result from the execution of the plan contained in the 
concrete case are determined. Therefore, each operator contained in the plan (starting from 
the first operator) is applied and the successor state is computed. This process starts at the 
initial state contained in the case and leads to a final state, which should be the goal state 
contained in the case. In phase-II, we derive all admissible abstractions for each concrete 
state computed in the first phase. For this purpose, the generic abstraction theory is used 
to determine all abstract sentences that can be derived from a respective concrete state by 
applying the rules of the generic abstraction theory. Figure 5 shows the abstract sentences 
that can be derived by the generic abstraction theory sketched above. For example, we can 
see that for the second concrete state an abstract description can be derived which contains 
two abstract sentences: the abstract sentence Ai required to achieve the type of abstraction 
shown in Figure 4 and additionally the abstract sentences required for abstraction by 
dropping sentences. Please note that by this process, the representation language of states 
is changed from concrete to abstract. The next two phases deal with the abstract operators. 
As already stated, abstract operators are given in the abstract language provided by the 
user. However, we do not assume operator abstraction rules which associate an abstract 
operator to a single concrete operator or a sequence of concrete operators. The reason for 
this is that such operator abstraction rules are extremely hard to acquire and even harder 
to keep complete. In the next two phases of case abstraction, we search for transitions of 
abstract states based on the available abstract operators. In phase-III, an acyclic directed 
graph is constructed. An edge leads from an abstract state I to a successor abstract state 
j (not necessarily to the next abstract state), if the abstract operator is applicable in state 
i and its application leads to the state j. The definition of the abstract operators are 
used in this process. The available abstract operators determine which transitions can be 
included in the graph. Figure 5 shows the resulting graph, provided that the abstract 
operators sketched in Section 3.3.1 are contained in the abstract language. In this graph 
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the transitions shown in plain line style result from the operators Oai, while the transitions 
shown in dashed line style result from the operators required for abstraction by dropping 
conditions. 

In phase-IV the graph is searched for consistent paths from the initial abstract state to 
the final abstract state. The paths must be consistent in the sense that in the resulting 
path (i.e., an abstract plan) every abstract operator is correctly applicable in the state that 
results from the previous operator. Moreover, the state abstraction which is required for 
this abstract plan must not change within the plan. In Figure 5 two paths of this kind are 
shown. The lower path represents the abstract planning case Cai (abstract initial and final 
state together with the operator sequence) that results from the kind of abstraction shown 
in Figure 4. The upper path represents the abstract planning case Ca 2 that results from 
abstraction by dropping the sentence El. This is the same abstract plan as shown in Figure 
2 for the problem X —?■ X'. Together with the two plans, the abstract state descriptions that 
result from the operator application are shown. Please note that these state descriptions 
are always a subset of the description which are derived by the generic abstraction theory. 
For example, the description of the fourth abstract state derived in phase-II, contains the 
sentences A^, A^, Aq. This abstract state occurs in both abstract cases which are computed 
in phase-IV. In the case Ca 2 , the respective state is described by the sentences A^ and 
Aq because these are the only sentences which result from the application of the operators 
starting at the abstract initial state. In the case Cai, the abstract state is described by 
the sentence A^ because this sentence results from the application of the operator Oa 2 . 
From this example we can see that the abstract operators have two functions. The first 
function is to select some of the concrete states that become abstracted. For example, in 
the abstract case Cai, the second concrete state is skipped, even if the first and the second 
concrete states can be abstracted to different abstract descriptions in phase-II. The reason 
for this is that there is no abstract operator that a) leads from the first abstracted state 
to the second abstracted state and which b) is also consistent with the other operators in 
the rest of the path. The second function of the abstract operators is to select some of the 
abstract sentences that are considered in the abstract planning case. For example, in the 
abstract case Cai, the sentences Ai,... , A 4 are considered while the sentences A 5 and Aq 
are left out. The reason for this is that the abstract operators Oai, Oa 2 , Oa^ which occur in 
the plan don’t use A 5 and Aq in their precondition and don’t manipulate these sentences. 

After phase-IV is finished, a set of abstract planning cases is available. These planning 
cases can then be stored in the case-base and used for further problem solving. 

3.3.4 Selecting and Reeining Abstract Cases 

During problem solving, an abstract case must be selected from a case-base, and the abstract 
plan contained in this case must be refined to become a solution to the current problem. 
During case retrieval we must search for an abstract case which is applicable, i.e., it contains 
a problem description that is an abstraction of the current problem. For example, assume 
that the problem V —?■ V' should be solved after the case X ^ X' was presented for learning. 
In this situation the case-base contains the two abstract cases Cai and Ca 2 shown in phase- 
IV of Figure 5. The abstract case Cai can be used for solving the new problem, because 
the initial state 000 of the new problem can be abstracted to Ai by applying the generic 
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Figure 6: Refinement of an abstract case for the solution of the problem Y ^ Y' 


abstraction theory. Similarly, the final state fOO can be abstracted to A 4 . However, the 
abstract case Ca 2 is not applicable because the final abstract state cannot be abstracted to 
Aq. Consequently, the lower abstract case must be used. During plan refinement we can 
refine the abstract operators sequentially from left to right as shown in Figure 6. Thereby 
each abstract operator defines an abstract goal state, i.e., the state that results after the 
execution of the operator. For example, the abstract operator Oai defines the abstract goal 
H 2 . To refine an abstract operator, we search for a concrete operator sequence, starting 
from the current concrete state (i.e., the initial state for the first operator), until a concrete 
state is reached that can be abstracted to the desired goal state. If such a state is found 
it can be used as a starting state for the refinement of the next abstract operator. For 
the solution of the problem Y —?■ Y', the refinement of the abstract operator Oai can be 
achieved by a sequence of two concrete operators leading to the concrete state IIO. This 
concrete state is then used as a starting state to refine the next abstract operator Oa 2 . 
This refinement procedure finishes if the last abstract operator is refined in a way that the 
final concrete state is achieved. Please note that in this type of refinement the operators 
themselves are not used directly, instead the sequence of states which results from their 
execution are used. Alternatively, we could have also stored an abstract case as a sequence 
of abstracted states. From our experience, storing a sequence of operators requires less 
space than storing a sequence of states. This will become obvious when looking at the 
domain that will be introduced in Section 8. Besides this the abstract operators play an 
important role in the learning phase. 

3.4 Relations to Skeletal Plans 

A similar experience-based or case-based variant for finding an abstract solution can be 
found in an early paper by Friedland and Iwasaki (1985) in which the concept of skeletal 
plans is introduced. A skeletal plan is ”[...] a sequence of generalized steps, which, when 
instantiated by specific operations in a specific problem context will solve a given problem 
[p.l61]. [...] Skeletal plans exist at many levels of generality. At the most general level, they 
are only a few basic plans, but these are used as ‘fall-backs’, when more specific, easier to 
refine plans cannot he found, [p. Ibf]. ” Skeletal plans are solutions to planning problems at 
different levels of detail and are consequently abstract plans. During problem solving they 
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are recalled from a library and refined towards a concrete solution. So this approach can be 
seen as an early idea for integrating abstraction and case-based reasoning. However, there 
are several differences between the skeletal plan approach and the Paris approach. In the 
skeletal plan approach no model of the operators (neither concrete nor abstract) is used to 
describe the preconditions and effects of operators as is done in Paris. There is no explicit 
notion of states and abstraction or refinement of states. Instead, the plan refinement is 
achieved by stepping down a hierarchy of operators, guided by heuristic rules for operator 
selection. In particular, no approach which supports the automatic acquisition of skeletal 
plans was provided. Unfortunately, the skeletal plan approach has not yet been investigated 
in as much detail as current work in the field of speedup-learning. There is neither a formal 
model of skeletal planning nor empirical evaluations. 

In the rest of this paper we will introduce and investigate the Paris approach more 
formally. 

4. Basic Terminology 

In this section we want to introduce the basic formal terminology used throughout the rest 
of this paper. Therefore we will define a formal representation for problem solving domains. 
We want to assume that problem solving in general can be viewed as transforming an initial 
state into a final state by using a sequence of operators (Newell & Simon, 1972). Following 
a STRlPS-oriented representation (Fikes & Nilsson, 1971), the domain of problem solving 
V = (£, S, O, TZ) is described by a first-order language® £, a set of essential atomic sentences 
S of £ (Lifschitz, 1987), a set of operators O with related descriptions, and additionally, a 
set of rules (Horn clauses) TZ out of L. The essential sentences (which must be atomic) are 
the only sentences that are used to describe a state. A state s G N describes the dynamic 
part of a situation in a domain and consists of a finite subset of ground instances of essential 
sentences of 8. With the symbol N, we denote the set of all possible states descriptions in a 
domain, which is defined as N = 2^*, with 8 * = {ea\e G 8 and cr is a substitution such that 
ea is ground}. In addition, the Horn clauses TZ allow the representation of static properties 
which are true in all situations. These Horn clauses must not contain an essential sentence 
in the head of a clause. 

An operator o{xi,... ,Xn) G (9 is described by a triple (Preg, Addo, Defi) , where the 
precondition PrOg is a conjunction of atoms of £, and the add-list Addg and the delete- 
list Delg are finite sets of (possibly instantiated) essential sentences of 8. Furthermore, 
the variables occuring in the operator descriptions must follow the following restrictions: 
{^i, ... , Xn} A Var{Preg) A Var{Delg) and {^i, ... , Xyfi A Var{Addg)7 

An instantiated operator is an expression of the form o{ti, ... fin), with ti being ground 
terms of £. A term ti describes the instantiation of the variable Xi in the operator descrip¬ 
tion. For notational convenience we define the instantiated precondition's well as the instan¬ 
tiated add-list and delete-list for an instantiated operator as follows: PrCg^^^^^^^ := PrCga, 

:= {aa\a£ Addg}, := {da\d£ Delg}, with (PrCg, Addg, Delg) is 

6. The basic language is first order, but with the deductive rules given in Horn logic only a subset of the 
full hrst-order language is used. 

7. These restrictions can however be relaxed such that {xi, . . . D Var(Preo) is not required. But the 

introduced restriction simplihes the subsequent presentation. 
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the description of the (uninstantiated) operator o{xi, ... , Xn), and a = , Xn/tn} 

is the corresponding instantiation. 

An instantiated operator o is applicable in a state s, if and only if s U 7^ h PrCg holds.® 
An instantiated operator o transforms a state si into a state S 2 (we write: si —^ S2) if and 
only if o is applicable in si and S 2 = (si \ Delg) U Addg. A problem description p = (s/, sq) 
consists of an initial state s/ together with a final state sq. The problem solving task 
is to find a sequence of instantiated operators (a plan) 0 = (oi,... ,o;) which transforms 
the initial state into the final state (s/ —L. ... AC. g|^)_ A case C = {p,b) is a problem 
description p together with a plan 0 that solves p. 

The introduced STRlPS-oriented formalism for defining a problem solving domain is 
similar in form and expressiveness to the representations typically used in general problem 
solving or planning. A state can be described by a finite set of ground atoms in which 
functions can also be used. Full Horn logic is available to describe static rules. The re¬ 
striction to Horn clauses has the advantage of being powerful while allowing efficient proof 
construction by using the well known SLD-refutation procedures (Lloyd, f984). Compared 
to the Prodigy Description Language (PDL) (Minton, f988; Blythe et ah, f992) our lan¬ 
guage does not provide explicit quantification by a specific syntactic construct, but a similar 
expressiveness can be reached by the implicit quantification in Horn clauses. Moreover, our 
language does not provide any kind of type specification for constants or variables as in 
PDL but we think that this is not a major disadvantage. Besides these points our language 
is quite similar to PDL. 

5. A Formal Model of Case Abstraction 

In this section we present a new formal model of case abstraction which provides a theory 
for changing the representation language of a case from concrete to abstract. As already 
stated we assume that in addition to the concrete language the abstract language is supplied 
by a domain expert. Following the introduced formalism, we assume that the concrete level 
of problem solving is defined by a concrete problem solving domain Vc = {Cc, Sc, OcTlc) 
and the abstract level of (case-based) problem solving is represented by an abstract prob¬ 
lem solving domain Va = {Ca, Sa, OajTla)■ For reasons of simplicity, we assume that both 
domains do not share the same symbols®. This condition can always be achieved by re¬ 
naming symbols. In the remainder of this paper states and operators from the concrete 
domain are denoted by s^ and respectively, while states and operators from the abstract 
domain are denoted by s“ and 0“ respectively. The problem of case abstraction can now be 
described as transforming a case from the concrete domain Vc into a case in the abstract 
domain Va (see Figure 7). This transformation will now be formally decomposed into two 
independent mappings: a state abstraction mapping a, and a sequence abstraction mapping 
/3 (Bergmann, 1992c). The state abstraction mapping transforms a selection of concrete 
state descriptions that occur in the solution to a problem into abstract state descriptions. 


8. In the following, we will simply omit the parameters of operators and instantiated operators in case they 
are unambiguous or not relevant. 

9. Otherwise, a symbol (or a sentence) could become ambiguous which would be a problem when applying 
the generic abstraction theory. It would be unclear whether a generic abstraction rule refers to a concrete 
or an abstract sentence 
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Figure 7: General idea of abstraction 


while the sequence abstraction mapping specifies which of the concrete states are mapped 
and which are skipped. 

5.1 State Abstraction 

A state abstraction mapping translates states of the concrete world into the abstract world. 

Definition 1 (State Abstraction Mapping) A state abstraction mapping a : Sc ^ Sa is a 
mapping from Sc, the set of all states in the concrete domain, to Sa, the set of all states in 
the abstract domain. In particular, a must be an effective total function. 

This general definition of a state abstraction mapping does not impose any restrictions 
on the kind of abstraction besides the fact that the mapping must be a total many-to- 
one function. However, to restrict the set of all possible state abstractions to a set of 
abstractions which a user considers useful, we assume that additional domain knowledge 
about how an abstract state relates to a concrete state can be provided. This knowledge 
must be expressed in terms of a domain specific generic abstraction theory A (Giordana, 
Roverso, & Saitta, 1991). 

Definition 2 (Generic Abstraction Theory) A generic abstraction theory is a set of Horn 
clauses of the form <— ai,... , a^,. In these rules e^ is an abstract essential sentence, 
i.e., Ca = EaCr for Ea G Sa and a substitution a. The body of a generic abstraction rule 
consists of a set of sentences from the concrete or abstract language, i.e., eii are atoms out 
of jCcA jCa- 

Based on a generic abstraction theory, we can restrict the set of all possible state abstraction 
mappings to those which are deductively justified by the generic abstraction theory. 

Definition 3 (Deductively Justified State Abstraction Mapping) A .state abstraction map¬ 
ping a is deductively justified by a generic abstraction theory A, if the following conditions 
hold for all s^ G Sc: 

• if f £ a(s^) then s^ U IZc A A\- 4> and 

• if 4> £ a(s^) then for all s^ such that s^ U IZc A A\- 4> holds, cj) £ a(s^) is also fulfilled. 
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In this definition the first condition assures that every abstract sentence reached by 
the mapping is justified by the abstraction theory. Additionally, the second requirement 
guarantees that if an abstract sentence is used to describe an abstraction of one state, it 
must also be used to describe the abstraction of all other states, if the abstract sentence can 
be derived by the generic abstraction theory. Please note that a deductively justified state 
abstraction mapping can be completely induced by a set a* C S* with respect to a generic 
abstraction theory as follows: a(s^) := {(j) G U TZc U d h (j)}. Unless otherwise stated 

we always assume deductively justified state abstraction mappings. To summarize, the 
state abstraction mapping transforms a concrete state description into an abstract state 
description and thereby changes the representation of a state from concrete to abstract. 
Please note that deductively justified state abstraction mappings need not to be defined 
by the user. They will be determined automatically by the learning algorithm that will be 
presented in Section 6. 

5.2 Sequence Abstraction 

The solution to a problem consists of a sequence of operators and a corresponding sequence 
of states. To relate an abstract solution to a concrete solution, the relationship between 
the abstract states (or operators) and the concrete states (or operators) must be captured. 
Each abstract state must have a corresponding concrete state but not every concrete state 
must have an associated abstract state. This is due to the fact that abstraction is always a 
reduction in the level of detail (Michalski & Kodratoff, 1990), in this situation, a reduction 
in the number of states. For the selection of those concrete states that have a corresponding 
abstraction, the sequence abstraction mapping is defined as follows: 

Definition 4 (Sequence Abstraction Mapping) A sequence abstraction mapping /3 : N —?■ N 
relates an abstract state sequence (sq, ... , sjj^) to a concrete state sequence (sjj,... , s))) by 
mapping the indices j G {1, • • • , m} of the abstract states Sj into the indices i G {1, • • • , ra} 
of the concrete states s?, such that the following properties hold: 

• /3(0) = 0 and (3{m) = n: The initial state and the goal state of the abstract sequence 
must correspond to the initial and goal state of the respective concrete state sequence. 

• (3{u) < (3{v) if and only if u < v: The order of the states defined through the concrete 
state sequence must be maintained for the abstract state sequence. 

Note that the defined sequence abstraction mapping formally maps indices from the abstract 
domain into the concrete domain. As an abstraction mapping it should better map indices 
from the concrete domain to indices in the abstract domain, such as the inverse mapping 
does. However, such a mapping is more inconvenient to handle formally since the 
range of definition of must always be considered. Therefore we stick to the presented 
definition. 

5.3 Case Abstraction 

Based on the two abstraction functions introduced, our intuition of case abstraction is 
captured in the following definition. 
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Figure 8: Different kinds of abstractions (a) and abstraction hierarchies (b) 


Definition 5 (Case Abstraction) A case Ca = {{sq, s'^), {o^,... , 0 '^)) is an abstraction 
of a case Cc = ((s§, s))), (o);,... ,of)) with respect to the domain descriptions {Vc,Va) if 

—A s? for all i G {1 ,... ,n} and ^ s“ for all j G {1,... , m} and if there 

exists a state abstraction mapping a and a sequence abstraction mapping [3, such that: 
Sj = holds for all j G {0, ... , m}. 

This definition of case abstraction is demonstrated in Figure 7. The concrete space shows 
the sequence of n operations together with the resulting state sequence. Selected states are 
mapped by a into states of the abstract space. The mapping /3 maps the indices of the 
abstract states back to the corresponding concrete states. 

5.4 Generality of the Case Abstraction Methodology 

In the following, we briefly discuss the generality of the presented case abstraction method¬ 
ology. We will see that hierarchies of abstraction spaces as well as different kinds of ab¬ 
stractions can be represented simultaneously using the presented methodology. 

5.4.1 Different kinds of Abstractions 

In general, there will be more than one possible abstraction of an object in the world. 
Abstraction can be performed in many different ways. An example of two different abstrac¬ 
tions of the same case has already been shown in the example in Figure 5. In this example, 
two different abstractions (see the abstract cases Cai and Ca 2 ) have been derived from the 
same concrete case. Our abstraction methodology is able cope with different abstractions 
in case they are specified by the user. Assume we are given one concrete domain Vc and 
two different abstract domains Vai and T>a 2 , each of which represents two different kinds 
of abstraction. Furthermore, assume that both abstract domains do not share the same 
symbols^®. We can always define a single abstract domain Va by joining the individual 
abstract domains which then includes both kinds of abstractions (see Figure 8 (a)). This 
property is formally captured in the following simple lemma. 

10. If the abstract domains are not disjoint, symbols can be simply renamed to achieve this property. 
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Lemma 6 (Joining different abstractions) If a concrete domain Vc and two disjoint ab¬ 
stract domains V^i and Va 2 are given, then a joint abstract domain = Vai U Va 2 can be 
defined as follows: LetVai = (£»!, ^ai, C>ai, i^ai) and let Va 2 = {jC.a 2 , £a 2 , Oa 2 ,Tla 2 ) ■ Then 
Va = Vai u Va 2 = (^ai U Ca 2 , ^ai U Sa 2 , C>ai U Oa 2 , 'hlai U Tla 2 ) ■ The joint abstract domain 
Va fulfills the following property: if Cf is an abstraction of Cf with respect to (Vc, Vai) or 
with respect to (Vc, Va 2 ), then Cf is also an abstraction of Cf with respect to [Vc,Va)- 

5.4.2 Hierarchy of Abstraction Spaces 

Most work on hierarchical problem solving assume a multi-level hierarchy of abstraction 
spaces for problem solving (e.g., Sacerdoti, 1974; Knoblock, 1989). Even if the presented 
approach contains only two domain descriptions, a hierarchy of abstract domains can simply 
be mapped onto the presented two-level model as shown in Figure 8 (b). Assume that a 
hierarchy of disjoint domain descriptions {Vq, ■ ■ ■ ,Vi) is given. In particular, the domain 
is assumed to be more abstract than the domain Uj,. In such a multi-level hierarchy 
of abstraction spaces, a case at the abstraction level Uj, is an abstraction of a case Co, if 
there exists a sequence of cases (Ci,... , C^-i) such that C is out of the domain Vi and Cq-i 
is an abstraction of C with respect to [Vi, Ui+i) for all i G {0, ... ,v — 1}. Such a multi¬ 
level hierarchy of domain descriptions can always be reduced to a two-level description. The 
abstract domain of this two-level description contains the union of all the levels from the 
multi-level hierarchy. This property is formally captured in the following lemma. 

Lemma 7 (Multi-Level Hierarchy) Let [Vq, ... ,Vi) he an arbitrary multi-level hierarchy 
of domain descriptions. For the two-level description (Vc, Va) with Va = U!/=i and 
Vc = Vq holds that: if Cf is an abstraction of Cf with respect to [Vq, ... ,Vi) then Cf is 
also an abstraction of Cf with respect to (Vc, Va). 

Since we have shown that different kinds of abstractions as well as hierarchies of abstrac¬ 
tion spaces can be directly represented within our two-level case abstraction methodology, 
we can further restrict ourselves to exactly these two levels. 

6. Computing Case Abstractions 

We now present the Pabs algorithm (Bergmann, 1992c; Wilke, 1993) for automatically 
learning a set of abstract cases from a given concrete case. Thereby, we assume that a 
concrete domain Vc and an abstract domain Va are given together with a generic abstraction 
theory A. We use the functional notation Cf G TAS>'^[(Vc,Va, A),Cc) to denote that Ca is 
an element of the set of abstract cases returned by the Pabs algorithm. 

The algorithm consists of the four separate phases introduced in Section 3. In the 
following we will present these phases in more detail. 

In the first three phases, we require a procedure for determining whether a conjunctive 
formula is a consequence of a set of Horn clauses. For this purpose, we use a SLD-refutation 
procedure (Lloyd, 1984) which is given a set of Horn clauses (a logic program) C together 
with conjunctive formula G (a goal clause). The refutation procedure determines a set of 
answer substitutions LI such that C h Ga holds for all a £ LI. We write LI = SLD(C, Gr). 
This SLD-refutation procedure performs some kind of backward-chaining and works as 
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follows. It selects a literal from the goal clause G (i.e., the left most literal) and searches 
for a Horn clause in the logic program C that contains a literal in its head that unifies with 
the selected goal literal. The selected literal is removed from G and the body (if not empty) 
of the applied clause is added at the beginning of the goal clause. Then the most general 
unifier of the goal literal and the head of the clause is applied to the whole new goal clause. 
The resulting goal clause is called resolvent. This process continues until the goal clause 
becomes empty or until no more resolvents can be built. In the former case, the goal has 
been proven and an answer substitution is computed by composing the substitutions used 
during resolution. Backtracking is used to look for possible other selections of applicable 
Horn rules to determine alternative answer substitutions. The set of all answer substitutions 
is returned as set ff. If the whole space of possible applications of the available Horn rules 
has been searched unsuccessfully, the goal clause is not a consequence of the logic program 
G and the SLD-refutation procedure terminates without an answer substitution (17 = 0). 
This must not be confused with the situation in which an empty substitution is returned 
(f7 = {0}), if no variables occur in G. In phase-HI of the Pass algorithm, we will also require 
the derivation trees in addition to the answer substitutions. Then we write H = SLD(C, G) 
and assume that H is a set of pairs (<7, r), where a is an answer substitution and r is a 
derivation of C h Ga. 

In order to assure the termination of the SLD-refutation procedure we have to require 
that the abstract domain and the generic abstraction theory is designed according to the 
following principles'^: 

• For each concrete state G Sc and each concrete operator G Oc where is 
described by (Pregc^ Addoc^ Delgc)^ SLD(s^ U TZct Preg^) must lead to a finite set of 
ground substitutions of all variables which occur in Pregc. 

• For each state abstract s“ G Sg and each abstract operator o“ G Og where o“ is 
described by (Prega, Addga, Delga), SLD(s“ U TZg, Prega) must lead to a finite set of 
ground substitutions of all variables which occur in Prega. 

• For each state G Sc and each abstract essential sentence E £ £g, SLD(s^U7^cUyl, E) 
must lead to a finite set of ground substitutions of all variables which occur in E. 

In the following the four phases of the Pass algorithm are explained in detail. 

6.1 Phase-I: Computing the Concrete State Sequence 

As input to the case abstraction algorithm, we assume a concrete case Gc = 
((sj, Sq), (o), ... , o)))). Note that (o),... , o))) is a totally ordered sequence of instanti¬ 
ated operators similar to the plans in Prodigy (Minton, 1988; Minton et ah, 1989; Veloso 
& Carbonell, 1993). In the first phase, the state sequence which results from the simulation 
of problem solution is computed as follows: 


11. At first glance, this restrictions seem a bit hard to achieve but if we take a closer look at it we can see 
that this is the standard requirement for a (terminating) logic program (i.e., a PROLOG program). 
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Algorithm 1 (Phase-I: Computing the concrete state sequence) 

Sq ;= s‘j 

for i := 1 to n do 

if SLD(s?_^ UTZc, Preo<r) = 0 then STOP “Failure: Operator not applicable” 

S' := (S'_i \ -De/oc) u Addoi 

end 

if 2 s)) then STOP “Failure: Goal state not reached” 

of 

By this algorithm, the states s? are computed, such that —)■ s? holds for all 

i G {1,... , n}. If a failure occurs the given plan is not valid, i.e., it does not solve the given 
problem. 

6.2 Phase-II: Deriving Abstract Essential Sentences 

Using the derived concrete state sequence as input, the following algorithm computes a 
sequence of abstract state descriptions (s“) by applying the generic abstraction theory 
separately to each concrete state. 

Algorithm 2 (Phase-II: State abstraction) 

for i := 0 to n do 

:= 0 

for each E £ £a do 

Q := SLD(s^"U7^cUA,E) 

for each a £ do 

s“:= s-U{Ea} 

end 

end 

end 

Please note that we have claimed that the domain theories are designed in a way that 
n is finite and only contains ground substitution of all variables in E. Therefore, every 
description s“ consists only of ground atoms and is consequently a valid abstract state 
description. Within the introduced model of case abstraction we have now computed a 
superset for the outcome of possible state abstraction mappings. Each deductively justified 
state abstraction mapping a is restricted by a(s?) C s“ = {e G U TZc O AS e} for all 

i £ {!,... ,ra}. Consequently, we have determined all abstract sentences that an abstract 
case might require. 

6.3 Phase-III: Computing Possible Abstract State Transitions 

In the next phase of the algorithm, we search for instantiated abstract operators which 
can transform an abstract state s“ C s“ into a subsequent abstract state s“ C s“ {i < j). 
Therefore, the preconditions of the instantiated operator must at least be fulfilled in the 
state s“ and consequently in also s“. Furthermore, all added effects of the operator must 
be true in s“ and consequently also in s“. 
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Algorithm 3 (Phase-Ill: Abstract state transitions) 

G := 0 

for i := 0 to ra — 1 do 
for j := i 1 to n do 

for each o{xi, ... , a;„) G Oa do 

let (PrCo, Delg, Addo) be the description of o{xi ,... , a;„) 

n := SLD(s“U7^a,Pre„) 

for each (a, r) G 11 do 

letAdd'g = {aa\a G Addg} 

(* Compute all possible instantiations *) 

(* of added sentences which hold in s“ *) 

M := {0} 

(* M is the set of possible substitutions *) 

(* initially the empty substitution. *) 

for each a G Add'^ do 
M' := 0 

for each 9 £ M do 
for each e G s“ do 

if there is a substitution p such that a9p = e then M' := M' U {Op} 

end 

end 

M := M' 

end 

(* Now, M contains the set of all possible substitutions *) 

(* such that all added sentences are contained in s“ *) 

for each 0 £ M do 

G ■.= GU {{i,j,o{xi,... ,Xu)(jO,t)} 

end 

end 

end 

end 

end 

The set of all possible operator transitions are collected as directed edges of a graph which 
vertices represent the abstract states. In the algorithm, the set G of edges of the acyclic 
directed graph is constructed. For each pair of states (s“,s“) with i < j it is checked 
whether there exists an operator o{xi, ... , Xu)cr which is applicable in s“. For this purpose, 
the SLD-refutation procedure computes the set of all possible answer substitutions a such 
that the precondition of the operator is fulfilled in s“. The derivation r which belongs 
to each answer substitution is stored together with the operator in the graph since it is 
required for the next phase of case abstraction. This derivation is an “and-tree” where 
each inner-node reflects the resolution of a goal literal with the head of a clause and each 
leaf-node represents the resolution with a fact. Note that for proving the precondition of 
an abstract operator the inner nodes of the tree always refer to clauses of the Horn rule set 
TZa, while the leave-nodes represent facts stated in TZa or essential sentences contained in 
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s“. Then each answer substitution a is applied to the add-list of the operator leading to a 
partially instantiated add-list Add'^. Note that there can still be variables in Add'^ because 
the operator may contain variables which are not contained in its precondition but may 
occur in the add-list. Therefore, the set M of all possible substitutions 9 is incrementally 
constructed such that a9 G s^j holds for all a G Add'^. The completely instantiated operator 
derived thereby is finally included as a directed edge (from i to j) in the graph G. 

By this algorithm it is guaranteed that each (instantiated) operator which leads from s“ 
to s“ is applicable in s“ and that all essential sentences added by this operator are contained 
in s“. Furthermore, if the applied SLD-refutation procedure is complete (it always finds all 
answer substitutions), then every instantiated operator which is applicable in s“ such that 
all essential sentences added by this operator are contained in s“ is also contained in the 

o“ 

graph. From this follows immediately that if a(s)j^j_^\) holds for an arbitrary 

deductively justified state abstraction mapping a and a sequence abstraction mapping [3, 
then {f3{i — f), o“, t) E G also holds. 

6.4 Phase-IV: Determining Sound Paths 

Based on the state abstractions s“ derived in phase-II and on the graph G computed in the 
previous phase, phase-IV selects a set of sound paths from the initial abstract state to the 
final abstract state. A set of significant abstract sentences a* and a sequence abstraction 
mapping /3 are also determined during the construction of each path. 

Algorithm 4 (Phase-IV: Searching sound paths) 

Paths :={((), 0,(/3(O) = O))} 

while there exists ((oj,... , o^), ee*, (3) G Paths with (3{k) < n do 
Paths := Paths \ ((oj,... , o^), a*, f3) 
for each {i,j, o“, t) E G with i = (3{k) do 

let T£ be the set of essential sentences contained in the derivation t 
let a' = Tf U Addga U a* 
if for all n E {1, • • • ,k} holds: 

(s;)(^_i) n a') ^ (s“(^) n a') and 
n a') (s“ n a') then 

Paths := Paths U {((oj,... , o^, o“), a', [3 U {f3{k -|- f) = j}) } 

end 

end 

GasesAbs '■= 0 

for each ((oj,... , o^), a*, (3) E Paths with (3{k) = n do 
GasesAbs ■= GasesAbs U {((sq F a*, s“ n a*), (o^,... , o^))} 

end 

return GasesAbs 

While the construction of the sequence abstraction mapping is obvious, the set a* repre¬ 
sents the image of a state abstraction mapping a and thereby determines the set of sentences 

12. Please note that ((o“, . . . ,of),a’‘,P) matches {((),0, (/3(0) = 0))} with k = 0. The operator \ denotes 
set difference. 
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that have to be reached in order to assure the applicability of the constructed operator se¬ 
quence. Note that from a* the state abstraction mapping a can be directly determined as 
follows: a(s?) = {e G Oi*\s‘i U TZc L) A e}. The idea of the algorithm is to start with an 
empty path. A path is extended by an operator from G in each iteration of the algorithm 
until the path leads to the final state with the index n. New essential sentences a' may 
occur in the proof of the precondition or as added effects of this new operator. The path 
constructed so far must still be consistent according to the extension of the state description 
and, in addition, the new operator must transform the sentences of a* correctly. 

As a result, phase-IV returns all cases that are abstractions of the given concrete input 
case with respect to concrete and abstract domain definitions and the generic abstraction 
theory. Depending on the domain theory, more than a single abstract case can be learned 
from a single concrete case as already shown in Figure 5. 

6.5 Correctness and Completeness of the PABS Algorithm 

Finally, we want to state again the strong connection between the formal model of case 
abstraction and the presented algorithm. The algorithm terminates if the domain descrip¬ 
tions and the generic abstraction theory are formulated as required in the beginning of this 
section, so that the SLD-resolution procedure always terminates. The algorithm is correct, 
that is every abstract case computed by the Pass algorithm is a case abstraction according 
to the introduced model. If the SLD-refutation procedure applied in Pass is complete every 
case which is an abstraction according to Definition 5 is returned by Pass. This property 
is captured in the following theorem. 

Theorem 8 (Correctness and completeness of the PABS algorithm) If a complete SLD- 
refutation procedure is used in the Pass algorithm, then Case Cf is an abstraction of case Cc 
with respect to {Vc, Da) and the generic theory A, if and only ifCf G PABS((Pcj Da, A), Cc)- 

6.6 Complexity of the Algorithm 

The complexity of the algorithm is mainly determined by the phases III and IV. The worst 
case complexity of phase-III is 0{n^ ■ Ci ■ C 2 ) where n is the length of the concrete plan 
and Cl and C 2 are dependent on the domain theories as follows: Ci = \Oa \ ■ |D| and C 2 = 
\Addoa \ • (|^a| • Thereby, \Oa \ represents the number of abstract operators, |D| is 

the maximum number of substitutions found by the SLD-refutation procedure, \Addof\ is 
the maximum number of added sentences in an abstract operator, and \8a\ is the number of 
abstract essential sentences. The complexity of phase-IV can be determined as • 

Cl). If we assume constant domain theories the overall complexity of the Pass algorithm can 
be summarized as 0{n ■ 2^”“^)). The exponential factor comes from possibly exponential 
number of paths in a directed acyclic graph with n nodes if every state is connected to 
every successor state. Whether a graph of this kind appears is very much dependent on 
the abstract domain theory, because it determines which transitions of abstract states are 
possible. This exponential nature does not lead to a time complexity problem in the domains 
we have used. Additionally, we want to make clear that this computational effort must be 
spent during learning and not during problem solving. If the time required for learning is 
very long, the learning phase can be executed off-line. 
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The space complexity of the algorithm is mainly determined by phase-III because all 
derivations of the proofs of the abstract operators’ preconditions must be stored. This can 
sum up to ■ Cl ■ C 2 derivations in the worst case. This did not turn out to be a problem 
in the domains we used because each derivation was very short (in most cases not more 
3 inferences with static Horn rules). The reason for this is that the derivations relate to 
abstract operators which very likely contain less preconditions than the concrete operators. 

7. Refinement of Abstract Cases 

In the previous section we have described how abstract cases can be automatically learned 
from concrete cases. Now we assume a case-base which contains a set of abstract cases. We 
want to show how these abstract cases can be used to solve problems at the concrete level. 
Furthermore, we discuss the impact of the specific form of the abstract problem solving 
domain on the improvement in problem solving that can be achieved. 

7.1 Applicability and Refinability of Abstract Cases 

For a given abstract case and a concrete problem description, the question arises in which 
situations the abstract case can be refined to solve the concrete problem. For this kind of 
refinability an a-posterior definition can be easily given as follows. 

Definition 9 (Refinability of an abstract case) An abstract case Ca can be refined to solve 
a concrete problem p if there exists a solution dc to p, such that Cf is an abstraction of 
{P,Oc). 

Obviously, the refinability property is undecidable in general since otherwise planning itself 
would be decidable. However, we can define the applicability of an abstract case as a 
decidable necessary property for refinability as follows. 

Definition 10 (Applicability of an abstract case) An abstract case Cf = 

{ofi ... , ofi)) can be applied to solve a concrete problem p = (sfi Sq) if there exists a state 
abstraction mapping a such that s“ G Im(a) for all i G {0,... , m} and a(sj) = Sq and 
a(s(L,) = s'fi. Thereby, Im(a) denotes the image of the state abstraction mapping a, i.e., all 
abstract states that can be reached. 

For an applicable abstract case, it is at least guaranteed that the concrete initial and goal 
states map to the abstract ones and that concrete intermediate states exists that can be 
abstracted as required by the abstract case. 

Even if applicability is a necessary precondition for refinability it does not formally 
guarantee refinability, since the downward solution property (Tenenberg, 1988), which states 
that every abstract solution can be refined, is a too strong requirement to hold in general 
for our abstraction methodology. However, it is indeed guaranteed that each abstract case 
contained in the case-base is already an abstraction of one or more previous concrete cases 
due to the correctness of the Pass algorithm used for learning. If one of the problems 
contained in these concrete cases has to be solved again it is guaranteed that the learned 
abstract case can be refined to solve the problem. Consequently, each abstract case in 
the case-base can at least be refined to solve one problem that has occurred in the past. 
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Abstract solutions which are useless because they can never be refined to solve any concrete 
problem will never be in the case-base and are consequently never tried in solving a problem. 
Therefore, we expect that each abstract case from the case-base has a high chance of being 
also refinable for new similar problems for which it can be applied. 

7.2 Selecting an Applicable Abstract Case 

To decide whether an abstract case can be applied to solve a concrete problem P, we 
have to determine a suitable state abstraction mapping. Because we assume deductively 
justified state abstraction mappings, the required state abstraction mapping a can always 
be induced by the set a* = UlIo shown in Section 5.1. Consequently, Ca is applicable 
to the problem p = (sj, Sq) if and only if Sq = {<!> G a* | Sj U T^c U A h <!>} and = {<!> G 
a* I s^UT^cUA h <!>}. Since every abstract case we use for solving a new problem has been 
learned from another concrete case, it is known that for each abstract state s“ there must 
be at least one concrete state (from that previous concrete state) that can be abstracted via 
a to s“. Consequently, s“ G Im(a) holds. Together with the introduced restrictions on the 
definition of A and TZc with respect to a complete SLD-refutation procedure (see Section 
6), the applicability of an abstract case is decidable. Algorithm 5 describes the selection of 
an applicable abstract case for a problem p = (s/>Sg) in more detail. 

Algorithm 5 (Selection of an applicable abstract case) 

:= s’}. := 0 

for each E £ £a do 

n := SLD(sJU7^cU A,.C) 

s'} := s}U[j^^^Ea 

for each E £ 8^ do 

81 := SLD(s^U7^cU A,.C) 

repeat 

repeat 

Select a new case Ca = ((so, Sm), (o}, ■ ■ ■ , o}^)) from the case base 
with Sq C s} and sf^ C sf, 
if no more cases available then 
refineoFlois}, (), 0, s)h) 
return the result ofrefineupiu 
for i := 1 to m — 1 do s“ := (s“_^ \ Delo^) U Addg^ 

:= ur=0 

until (sj n a*) = Sq and (s)b fl a*) = s}^ 
refineDFlois}, (sJ,... , s^_i), a*, s)h) 
until refine£)pi£) returns success(p) 
return success(p) 

At first, the initial and final concrete states of the problem are abstracted using the 
generic abstraction theory. Thereby, an abstract problem description (s'), Sq) is determined. 
Then, in a pre-selection step, an abstract case is chosen form the case base. All of the 
abstract sentences contained in the initial and final abstract state of this case must be 
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contained in the abstracted problem description This condition, however, does not 

guarantee that the selected case is applicable with respect to Definition 10. The set a* 
of abstract sentences inducing the respective state abstraction mapping is computed and 
the applicability condition is checked to test whether the selected case is applicable. If 
the selected case is not applicable, a new case must be retrieved. If an applicable abstract 
case has been determined the refinement algorithm refineupiu (see following section) is 
executed. This algorithm uses the sequence of intermediate abstract states (sj,... , 
previously determined from the abstract plan of the case, to guide the search at the concrete 
level. The operators contained in the abstract plan are not used anymore. The refinement 
procedure returns success{p), if the refinement succeeds with the solution plan p. If the 
refinement fails (the procedure returns failure), another case is selected. If no more cases 
are available the problem is solved by pure search without any guidance by an abstract 
plan. 


7.3 Refining an Abstract Plan 

The refinement of a selected abstract case starts with the concrete initial state from the 
problem statement. The search proceeds until a sequence of concrete operations is found 
which leads to a concrete state such that sj = {()> G a* | U TZc yj A \- <f\ holds. The 
applicability condition of the abstract case guarantees that such a state exists (s“ G Im(a)) 
but it is not guaranteed that the required concrete operator sequence exists too. Therefore, 
this search task may fail which causes the whole refinement process to fail also. If the first 
abstract operator can be refined successfully a new concrete state is found. This state can 
then be taken as a starting state to refine the next abstract operator in the same manner. 
If this refinement fails we can backtrack to the refinement of the previous operator and try 
to find an alternative refinement. If the whole refinement process reaches the final abstract 
operator it must directly search for an operator sequence which leads to the concrete goal 
state Sq. If this concrete goal state has been reached the concatenation of concrete partial 
solutions leads to a complete solution to original problem. 

This refinement demands for a search procedure which allows an abstract goal specifi¬ 
cation. All kinds of forward-directed search such as depth-first iterative-deepening (Korf, 
1985b) or best-first search (Korf, 1993) procedures can be used for this purpose because 
states are explicitly constructed during search. These states can then be tested to see if they 
can be abstracted towards the desired goal. In Paris we use depth-first iterative-deepening 
search described by Algorithm 6. This algorithm consists of two recursive procedures. The 
top-level procedure refineupiu receives the concrete initial state sf the concrete final state 
Sq, the sequence of intermediate abstract states 5“ = (sj,... , s^) derived from the abstract 
case, as well as the set a* which induces the state abstraction mapping. This procedure 
increments the maximum depth for the depth-first search procedure searchfjounded up to the 
maximum Deepj,^^^^. The procedure searchfjounded performs the actual search. The goal for 
this search is either an abstract state, i.e., the first abstract state in 5“, or the concrete 
goal state Sq if all abstract state have already been visited. The procedure performs a 
depth-first search by applying the available concrete operators and recursively calling the 
search procedure with the concrete state which results from the operator application. 
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If an abstract goal state has been reached it is removed from the list 5“ and the refinement 
continues with the next abstract state which is then again the first one in the list. 

Algorithm 6 (Refinement by depth-first iterative-deepening (DFID) search) 

procedure refine£)FlD{s% 5*“, a*, Sq) 

Deep := 0 

repeat 

searchbounded{s‘}, 5“, a*, Deep) 

if searchbounded returns success(p) then return success(p) 

Deep := Deep -|- 1 (* Search unsuccessful: Increment search deepness *) 
until Deep = DeepMax 
return failure 

procedure searchbounded{s% 5“, «*, Deep) 

if 5“ = 0 (* No more abstract goals: Test the concrete final goal *) 
and Sj = then return success(()) 
if 5“ = (sj,... , s^) (* At least one abstract goal *) 
and for all e G sj holds: SLD(sj U TZc U A, e) / 0 
and for all e G a* \ sj holds: SLD(sj U TZc U A, e) = 0 
then (* Abstract state reached: Refine next abstract operator *) 
refineDFlD{s‘i, {s2, • • • , Sfc), «*, ■§(?) 

if refine£)pi£) returns success(p) then return success(p) 
if Deep = 0 then return failure (* Maximum depth reached *) 

(* Apply operators: Create successor states *) 

for all o^ G Oc do 

D = SLD(sj U TZc, Pregc) (* D is the set of all possible operator instantiations *) 

for each cr G D do 

sf^^ := (sj \ (Delgca)) U (Addoca) (* Create successor state *) 
searchboundedisfe,^, 5*“, a*, Sq, Deep — 1) (* Continue search with new state *) 
if searchbounded returns success(p) then return success[fo‘^a) op)) 
return failure 

Please note that this kind of refinement is different from the standard notion of refine¬ 
ment in hierarchical problem solving (Knoblock et ah, 1991b). This is because there is 
no strong correspondence between an abstract operator and a possible concrete operator. 
Moreover, the justification structure of a refined abstract plan is completely different from 
the justification structure of the abstract plan itself because of the completely independent 
definition of abstract and concrete operators. Even if this is a disadvantage compared to the 
usual refinement procedure used in hierarchical problem solving, the main computational 
advantage of abstraction caused by the decomposition of the original problem into smaller 
subproblems is maintained. 

7.4 Alternative Search Procedures for Refinement 

Besides the forward-directed search procedure currently used in Paris backward-directed 
search as used in means-end analysis (Fikes & Nilsson, 1971) or in nonlinear partial-ordered 
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planning (McAllester & Rosenblitt, 1991) can also be applied for refinement under certain 
circumstances. Therefore, we would either require a state concretion function or we have 
to turn the rules of the generic abstraction theory A into virtual concrete operators. 

A state concretion function must be able to determine a single state or a finite set of 
concrete states from a given abstract state together with the concrete problem description. 
Thereby, the concrete problem description may help to reduce the number of possible con¬ 
crete states. The derived state concretions can then be used as concrete goal states from 
which a backward directed search may start. 

Alternatively, we can turn the process of state concretion directly into the search pro¬ 
cedure by representing each rule in the generic abstraction theory as a virtual abstract 
operator. The precondition of a rule in the generic abstraction theory becomes the pre¬ 
condition of the virtual operator and the conclusion of the rule becomes a positive effect 
of this operator. When using the virtual concrete operators together with the operators of 
the concrete domain, a backward-directed planner can use the abstract state directly as a 
goal for search. The part of the plan in the resulting solution which only consists of con¬ 
crete operators (and not of virtual operators) can be taken as a refinement of the abstract 
operator. 

7.5 Criteria for Developing an Abstract Problem Solving Domain 

The abstract problem solving domain and the generic abstraction theory used have an im¬ 
portant impact on the improvement in problem solving that can be achieved. Therefore, 
it is desirable to have a set of criteria which state how a “good“ abstract domain defini¬ 
tion should look. Strong criteria allowing quantitative predictions of the resulting speedups 
can hardly be developed. For other hierarchical planners such criteria don’t exist either. 
However, we can give a set of factors which determine the success of our approach. The 
overall problem solving time is influenced mainly by the following four factors: indepen¬ 
dent refinability of abstract operators, goal distance of abstract operators, concrete scope of 
applicability of abstract operators, and the complexity of the generic abstraction theory. 

7.5.1 Independent Reeinability oe Abstract Operators 

Following Korf’s analysis of hierarchical problem solving (Korf, 1987) introduced in 
Section 2, our plan refinement approach reduces the overall search space from 5” to 
Y,T=i Thereby, b is the average branching factor, n is the length of the con¬ 

crete solution, and /3 is the sequence abstraction mapping used in the abstraction of the 
concrete case to the abstract case. As already mentioned, we cannot guarantee that an 
abstract plan which is applicable to a problem can really be refined. Furthermore, Korf’s 
analysis assumes that no backtracking between the refinement of the individual abstract 
operators is required which cannot be guaranteed. Some of the computational advantage 
of abstraction is lost in either of these two cases. 

However, if the abstract operators occurring in the abstract problem solving domain 
fulfill the strong requirement of independent refinability, then it is guaranteed that every 
applicable abstract case can be refined without any backtracking. An abstract operator o“ 
is independently refinable if for each s^, s^ G Sc and every state abstraction mapping a if 
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a(s^) a(s^) holds, then there exists a sequence of concrete operators (oj,... , o^) such 

that —4- ... —^ holds. 

The problem with this requirement is that it seems much to hard to develop an abstract 
problem solving domain in which all operators fulfill this requirement. Although we cannot 
expect that all operators in the abstract problem solving domain are independently refinable, 
a knowledge engineer developing an abstract domain should still try to define abstract 
operators which can be independently refined in most situations, i.e., for most s^, s^ G Sc 
and most state abstraction mapping a an applicable abstract operator can be refined to a 
concrete operator sequence. Although this notion of mostly independent refinability is not 
formal we feel that it is practically useful when developing an abstract domain definition. 
The more abstract operators that can be refined independently in many situations, the 
higher is the chance that an abstract plan composed of these operators is also refinable. 

7.5.2 Goal Distance of Abstract Operators 

The goal distance (cf. subgoal distance, Korf, f987) is the maximum length of the sequence 
of concrete operators required to refine a particular abstract operator. The longer the goal 
distance the larger is the search space required to refine the abstract operator. In particular, 
the complexity of the search required to refine a complete abstract plan is determined 
by the largest goal distance of the abstract operators that occur in the abstract plan. 
Hence there is a good reason to keep the goal distance short. However, the goal distance 
negatively interacts with the next factor, namely the concrete scope of applicability of 
abstract operators. 

7.5.3 Concrete Scope of Applicability of Abstract Operators 

The concrete scope of applicability of an abstract operator specifies how many concrete 
states can be abstracted to an abstract state in which the abstract operator is applicable, 
and how many concrete states can be abstracted to an abstract state that can be reached 
by an abstract operator. This scope is determined by the definition of the abstract operator 
and by the generic abstraction theory which is responsible for specifying admissible state 
abstractions. The concrete scope of applicability of the abstract operators determines the 
applicability of the abstract plans that can be learned. An abstract plan which is only ap¬ 
plicable to a few concrete problems is only of limited use in domains in which the problems 
to be solved vary very much. Hence, the concrete scope of applicability of abstract oper¬ 
ators should be as large as possible. Unfortunately, according to our experience, abstract 
operators which have a large scope usually also have a larger goal distance and operators 
with a short goal distance don’t have a large scope of applicability. Therefore, a compromise 
between these two contradicting issues must be found. 

7.5.4 Complexity of the Generic Abstraction Theory 

The fourth factor which influences the problem solving time is the complexity of the generic 
abstraction theory. This theory must be applied each time a new concrete state is created 
during concrete level search. The more complex the generic abstraction theory, the more 
time is required to compute state abstractions. Hence, the generic abstraction theory should 
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not require complicated inferences and should avoid backtracking within the SLD-refutation 
procedure. 

Although these four factors don’t allow a precise prediction of the expected problem 
solving behavior of the resulting system, they provide a focus on what to consider when 
designing an abstract problem solving domain and related generic abstraction theory. 

8. An Example Domain: Process Planning in Mechanical Engineering 

The Paris approach has been successfully tested with toy-domains such as the familiar 
towers of Hanoi (Simon, 1975). For these domains, hierarchical problem solvers which use 
a dropping sentence approach have also proven very useful (Knoblock, 1994). 

This section presents a new example domain we have selected from the field of pro¬ 
cess planning in mechanical engineering and which really requires a stronger abstraction 
approach.^® We have selected the goal of generating a process plan for the production of 
a rotary-symmetric workpiece on a lathe. The problem description, which may be derived 
from a CAD-drawing, contains the complete specification (especially the geometry) of the 
desired workpiece (goal state) together with a specification of the piece of raw material 
(called mold) it has to be produced from (initial state). 

The left side of Figure 9 shows an example of a rotary-symmetric workpiece which has to 
be manufactured out of a cylindrical mold.^'^ Rotary parts are manufactured by putting the 
mold into the fixture (chuck) of a lathe. The chucking fixture, together with the attached 
mold, is then rotated with the longitudinal axis of the mold as rotation center. As the 
mold is rotated a cutting tool moves along some contour and thereby removes certain parts 
of the mold until the desired goal workpiece is produced. Within this process it is very 
hard to determine the sequence in which the specific parts of the workpiece have to be 
removed and the cutting tools to be used. When a workpiece is chucked a certain area of 
the workpiece is covered by the chucking tool and cannot be processed by a cutting tool. 
Moreover, a workpiece can only be chucked if the area which is used for chucking is plain. 
Otherwise the fixation would not be sufficiently stable. Hence, many workpieces are usually 
processed by first chucking the workpiece on one side and processing the accessible area. 
Then the workpiece is chucked at the opposite side and the area that was previously covered 
can be processed. Processing the example workpiece shown in Figure 9 requires that the 
workpiece is first chucked at the left side while the right side is processed. Then the processed 
right side can be used to chuck the workpiece because the area is plain and allows stable 
fixing. Hence, the left side of the workpiece including the small groove can be processed. 
Now we explain the representation of this domain in more detail. The complete definition 
of the domain can be found in Online Appendix f. Several simplifications of the real 
domain were required in order to obtain a domain definition that could be efficiently handled 
in a large set of experiments. One restriction is that we can only represent workpieces 
with right-angled contour elements. For example, a conical contour cannot be represented. 
Many different cutting and chucking tools are available in real-life process planning. We 

13. This domain was adapted from the CAPLAN-System (Paulokat & Wess, 1994), developed at the Univer¬ 
sity of Kaiserslautern. 

14. Note that this hgure shows a 2-dimensional drawing of the 3-dimensional workpiece. The measure 1 in. 

equals 25.4 mm. 
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An Example Workpiece Grid Representation for the example workpiece 

2 mm 


y 




Figure 9: An example workpieces with grid representation 


have restricted ourselves to a single chucking tool and three different cutting tools. The 
specification of the tools themselves have also been simplified. For example, the rotation 
speed of workpiece and the feed of the cutting tool are also parameters that can play a 
role when processing a workpiece. The impact of these parameters has also been neglected. 
Despite these simplifications the remaining part of this real-world domain is not trivial and 
represents a substantial subset of the most critical problems in this domain. 

8.1 Concrete Domain 

We now explain the concrete problem solving domain by giving a detailed description of 
the states and the operators. 

8.1.1 State Description 

For the representation of this domain at the concrete level, the exact geometry of the 
workpiece must be represented as a state, including the specific measures of each detail 
of the contour. However, the complete workpiece can always be divided into atomic areas 
which are always processed as a whole. Therefore the state representation is organized by 
using a grid which divides the entire workpiece into several disjoint rectangular areas of 
different sizes (see the right side of Figure 9). Together with a grid coordinate the specific 
position and size of the corresponding rectangular area are represented. This grid is used 
as a static part of the state description which does not change during planning. However 
different problems require different grids. The specific shape of a workpiece during planning 
is represented by specifying the status for each grid rectangle. In Table 1 the predicates 
used to represent the workpiece are described in more detail. 

Besides the description of the workpiece, the state representation also contains informa¬ 
tion about how the workpiece is chucked and which kind of cutting tool is currently used. 
Table 2 describes the predicates which are used for this purpose. 
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Predicate Description 

xpos_max The predicates xpos_max(xgrid) and ypos_max(ygrid) specify the size of the 
ypos_max grid in the direction of the x-coordinate and the y-coordinate respectively. 

A state consists of exactly one instance of each of these predicates, e.g., 
xpos_max(4) and ypos_max(5) in the example shown in Figure 9. 

grid_xpos The predicates grid_xpos(xg„d, Xstart, Xsize) and grid_ypos(ygridi Vstart, Usize) 
grid_ypos specify the geometrical position and size of grid areas in the direction of 
the x-coordinate and y-coordinate respectively. The first argument of these 
predicates specifies the coordinate of the grid areas, the second argument 
declares the geometrical starting position, and the third argument specifies 
the size of the grid areas. A state consists of exactly one instance of each of 
these predicates for each different x-coordinate and y-coordinate. For the 
example above, grid_xpos(l,0,18), grid_xpos(2,18,2), grid_xpos(3,20,165), 
grid_xpos(4,185,40) specify the grid in x-direction and grid_ypos( 1,0,8), ..., 
grid_ypos(5,26,8) specify the grid in y-direction. 

mat The predicate mat(x gru , y grid, status) describes the status of a particular 

grid area specified by the coordinates {xgrid, ygrid)- The argument status 
can be instantiated with one of the three constants raw, workpiece, or none. 
The constant raw indicates that the specified area still consists of raw ma¬ 
terial which must be removed by further cutting operators. The constant 
workpiece specifies that the area consists of material that belongs to the 
goal workpiece. The constant none specifies that the area does not contain 
any material, i.e., there was no material present in the mold or the material 
has already been removed by previous cutting operations. One instance of 
a mat predicate is required for each grid area to specify its current state. 
While the previously mentioned predicates does not change during the exe¬ 
cution of a plan, the mat predicate is changed by each cutting operator. In 
particular, the initial state and the goal state of a problem differs in the sta¬ 
tus assigned to those grid areas that must become removed. For example, 
in the initial state of the example shown above, the sentence mat(4,2,raw) 
will be present while the final state contains the sentence mat(4,2,none). 

Table I: Essential sentences for the representation of the workpiece 

8.1.2 Operators 

A process plan to manufacture a certain workpiece consists of a sequence of operators. The 
total order of the operators is not a problem for this domain because the manufacturing 
steps are also executed sequentially on a lathe.We have chosen four different operators 

15. However, there are also a few new brands of lathe machine which also allow parallel processing. 
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Predicate Description 

chuck_pos The predicate chuck_pos(side) describes whether the workpiece is currently 
chucked on either side. The parameter side can be instantiated with one 
of the three constants none, right, or left. The constant none specifies that 
the workpiece is not chucked at all and the constants right and left specify 
that the workpiece is chucked at the respective side. Each state contains 
exactly one instance of this predicate. 

covered The predicate covered (x,min, x^ax) specifies the areas of the workpiece which 

are currently covered by the chucking tool. This predicate declares those 
areas with an x-coordinate lying within the interval [x-mim Xmax] as being 
covered. Covered areas cannot be processed by a cutting tool. A state 
consist of exactly one instance of this predicate if the workpiece is chucked. 

cut_tool The predicates cut_tool(id) and cut_direction(dir) specify a unique identi- 

cut_direction fication (id) of the cutting tool which is currently used when an area is 
processed and the direction (dir) in which the cutting tool moves. The pa¬ 
rameter id can be any symbol that specifies a legal cutting tool described 
by predicates included in the static rules TZc of the concrete domain descrip¬ 
tion. The parameter dir can be instantiated by one of the three constants 
left, right and center. The value left specifies that the cutting tool moves 
from left to right, right specifies that the cutting tool moves from right to 
left, and center specifies that the cutting tool move from outside towards 
the center of the workpiece. 

Table 2: Essential sentences for the representation of the chucking and cutting tools 

to represent the chucking of a workpiece, the selection of a cutting tool, and the cutting 
process itself. These operators are described in Table 3. 

Manufacturing the workpiece shown in Figure 9 requires a f5-step plan as shown in 
Figure fO. At first, the workpiece is chucked on the left side. Then a cutting tool is selected 
which allows cutting from right to left. With this tool the indicated grid areas are removed. 
Please note that the left side of the workpiece cannot be processed since it is covered by 
the chucking tool. Then (see the right side of Figure fO), the workpiece is unchucked and 
chucked on its right side. With a tool that allows processing from left to right, the upper 
part of the mold is removed. Finally, a specific tool is used to manufacture the small groove. 

8.2 Abstract Domain 

In this example we can see that the small groove can be considered a detail which can be 
processed after the basic contour of the workpiece has been established. The most important 
characteristic of this example is that the right part of the workpiece is processed before the 
left side of the workpiece. This sequence is crucial to the success of the plan. If the groove 
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Operator Description 

chuck The operator chuck(side) specifies that the workpiece is chucked at the 

specified side. The side parameter can be instantiated with the constants 
left and right. Chucking is only allowed if the workpiece is not chucked al¬ 
ready and if the surface used for chucking is plain. As effect of the chucking 
operation, respective instances of the predicate chuck_pos and covered are 
included in the state description. 

unchuck The operator unchuck specifies that the chucking of the workpiece is re¬ 
moved. This operation can only be executed if the workpiece is chucked al¬ 
ready. As effect of this operation, the parameter of the predicate chuck_pos 
is changed to none and the predicate covered is deleted. 

use_tool The operator use_tool(dir,id) specifies which tool is selected for the sub¬ 

sequent cutting operators and in which direction the cutting tool moves. 
The workpiece must be chucked before a tool can be chosen. The effect 
of the operator is that respective instantiations of the predicates cut_tool 
and cut_direction are added to the state. The parameters of the useJool 
operator have the same definition as in the respective predicates. 

cut The operator cut(xgrid, ygrid) specifies that the raw material in the grid 

area indicated by the coordinates {xgrid, Vgrid) is removed. The effect of 
this operator is that the predicate mat which specifies the status of this 
particular area is changed from status raw to the status none. However, to 
apply this operator several preconditions must be fulfilled. The workpiece 
must be chucked and the chucking tool must not cover the specified area 
and the area must be accessible by the cutting tool. Moreover, a cutting 
tool which allows the processing of the selected area must already have been 
selected. Each cutting tool imposes certain constraints on the geometrical 
size of the area that can be processed with it. For details, see the full 
description of the domain in Online Appendix f. 

Table 3: Concrete operators 

would have been processed first the workpiece could never be chucked on the left side and 
the processing of the right side would consequently be impossible. Domain experts told us 
that this situation is not specific for the example shown. It is of general importance for 
many cases. This fact allows us to select parts of the problem description and the solution 
which can be considered as details from which we can abstract. Parts which are “essential” 
must be maintained in an abstract case. We found out that we can abstract from the 
detailed shape of the workpiece as long as we distinguish between the processing of the left 
and right side of the workpiece. Furthermore, it is important to distinguish between the 
rough contour of the workpiece and the small details such as grooves. We have developed 
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-1. chuck(left) 

2.-6. use_tool(right, t2), cut(4,5),...,cut(4,2) 



7.-8. unchuck, chuck(right) 


— 9.-12. use_tool(left,tl),cut(l,5),..,cut(3,5) 
13.-15. use_tool(center,t3), cut(2,4), unchuck 



Figure 10: A plan for manufacturing the workpiece 


an abstract domain definition containing a new language for describing states and operators 
based on this abstraction idea. 

8.2.1 State Description 

We introduce a new abstract grid which divides the workpiece into a left, a middle, and a 
right area to abstract from the specific location of a concrete grid area. These areas are 
called complex processing areas. Each area is assigned a particular status. Furthermore, 
an abstract state contains the information whether a complex processing area contains 
small contour elements (such as grooves), but not how these grooves exactly look like. To 
abstract from the very detailed conditions for chucking a workpiece, an abstract state only 
contains an approximation of these conditions, stating that a workpiece cannot be chucked 
at a particular side, if this side contains small contour elements that have been already 
processed. The predicates used to represent an abstract state are described in more detail 
in Table 4. 

8.2.2 Operators 

We consider an abstract operator which completely processes one complex area of the 
workpiece, an operator which only processes a complex area roughly, and an operator which 
processes all the small grooves of a complex area. We also consider an abstract chucking 
operator because the chucking has a strong impact on the overall plan. Table 5 shows the 
available abstract operators. 

8.3 Generic Abstraction Theory 

The generic abstraction theory defines the sentences used to describe an abstract state (see 
Table 4) in terms of the sentences of the concrete state (see Tables f and 2) by a set of 
Horn rules. The definition of abstract sentence is explained in more detail in Table 6. 
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Predicate Description 

abs_area_state The predicate abs_area_state(area, status) describes the status of 

each of the three complex processing areas. The argument area 
specifies one of the complex processing areas left, middle, and right. 
The argument status describes the status of the respective area. 
The status can be either todo, rough, and ready. The status todo 
specifies that the area needs some processing of large contour ele¬ 
ments, while in a rough area only some small contour elements such 
as grooves need to be processed. The status ready specifies that 
the area is completed. An abstract initial state usually contains 
one or more complex processing areas of the status todo, while in 
the abstract goal state all complex processing areas have the status 
ready. 

abs_smalLparts The predicate abs_smalLparts(area) specifies that the complex pro¬ 

cessing area (area) contains small contour elements that need to be 
manufactured. 

abs_chuck_pos The predicate abs_chuck_pos(side) describes whether the workpiece 

is currently chucked on either side. The parameter side can be 
instantiated with one of the three constants none, right, or left. This 
predicate has exactly the same meaning as the chuck_pos predicate 
at the concrete level. This predicate is not abstracted at all but 
only renamed. 

abs_chuckable_wp The predicate abs_chuckable_wp(side) describes whether the work- 
piece can be be chucked at the left or right side if this side has been 
completely processed. 

Table 4: Essential sentences for describing an abstract state 

We have strongly considered the factors that influence the quality of a domain (see Sec¬ 
tion 7.5) during the development of the abstract problem solving domain and the generic 
abstraction theory. Although none of the defined abstract operators is independently re- 
finable, all of them are mostly independently refinable. The preconditions of each abstract 
operator still contains approximations of the conditions that must be fulfilled in order to as¬ 
sure that a concrete operator sequence exist that refines the abstract operator. For example, 
the predicate abs_chuckable_wp(side) is an approximation of the detailed condition (a plain 
surface) required for chucking. The goal distance of each operator is quite different and 
strongly depends on the problem to be solved. While the goal distance of the set_fixation 
operators is no more than two (possibly one unchuck operator followed by a chuck operator) 
the goal distances of the other abstract operators are different. For example, the goal dis¬ 
tance of the process_ready operator depends on the number of concrete grid areas belonging 
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Operator Description 

set_fixation The operator set_fixation(side) specifies that the workpiece is chucked 

at the specified side. The side parameter can be instantiated with the 
constants left, right and none. The constant none specifies that the 
chucking is removed. Compared to the concrete operator chuck the 
preconditions for chucking at a side have been simplified. The effect of 
this operator is that the predicate ahs_chuck_pos is modified. 

process_rough The operator process_rough(area) specifies that the complex processing 

area (area) is being processed completely up to the small contour ele¬ 
ments. The parameter area can be either left, middle, or right. The 
precondition of this operator only requires that the workpiece is chucked 
at a different side than area. The effect of this operator is that the pred¬ 
icate ahs_area_state is modified. 

processjine The operator process_fine(area) specifies that all small contour elements 
of the complex processing area (area) are being processed. The param¬ 
eter area can be either left, middle, or right. The precondition of this 
operator only requires that the large contour elements of this side of 
the workpiece are already processed and that the workpiece is chucked 
at a different side. The effect of this operator is that the predicate 
ahs_area_state is modified. 

process_ready The operator process_ready(area) specifies that the indicated complex 
area of the workpiece is being completely processed, including large and 
small contour elements. The effect of this operator is that the predicate 
ahs_area_state is modified. 

Table 5: Abstract operators 

to the respective abstract area and containing material that needs to be removed. The 
goal distance is the number of these gird areas, say c, plus the number of required useJool 
operations (less than or equal to c). Hence, the goal distance is between c and 2c. Because 
this goal distance can become very long for the more complex problems, the two operators 
process_rough and process_fine are introduced. They only cover the processing of the small 
and the large grid areas respectively and consequently have a smaller goal distance than 
the process_ready operator. While the goal distance of these two operators is smaller they 
have a smaller concrete scope of applicability than the process_ready operator. For example 
the process_ready operator can be applied in any state in which some arbitrary areas need 
to be processed, but processjine can only be applied in states in which all large grid areas 
are already processed. 

Although we have only developed a simplified version of the whole domain of produc¬ 
tion planning in mechanical engineering for rotary symmetrical workpieces we feel that 
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Abstract Predicate Description in terms of the predicates of the concrete domain 
abs_area_state The predicate abs_area_state(area, status) describes the status of 

each of the three complex processing areas. The left processing area 
consists of the areas of the concrete grid which are covered, if the 
workpiece is chucked at the left side. Similarly, the right processing 
area consists of those concrete grid areas which are covered if the 
workpiece is chucked at the right side. The middle processing area 
consists of those areas which are never covered by any chucking 
tool. The status of a complex processing area is todo, if there exists 
a concrete large grid area which belongs to the complex processing 
area and which needs to be processed. A grid area is considered 
as large if its size in direction of the x-coordinate is larger than 3 
mm. The status of a complex processing area is rough, if all large 
grid areas of the complex processing area are already processed 
and if there exists a concrete small grid area which belongs to the 
complex processing area and which needs to be processed. A gird 
area is considered as small if its size in direction of the x-coordinate 
is smaller or equal than 3 mm. The status of a complex processing 
area is ready if all concrete grid areas which belong to the complex 
processing area have been processed. 


abs_smalLparts The sentence abs_smalLparts(area) holds if there exists a small con¬ 

crete grid area (size smaller or equal than 3 mm) which belongs to 
the complex processing area and which needs to be processed. 

abs_chuck_pos The sentence abs_chuck_pos(side) holds if and only if the concrete 

sentence chuck_pos(side) holds. 

abs_chuckable_wp The predicate abs_chuckable_wp(side) describes whether the work- 
piece can still be chucked at the left or right side if this side is 
completely processed. This sentence holds if the part of the desired 
workpiece which belongs to respective side is completely plain. That 
is, all concrete grid areas with the status workpiece range up to the 
same y-coordinate. 


Table 6: Generic abstraction theory 


a domain expert together with a knowledge engineer will be able to define an abstract 
domain representation and a generic abstraction theory for a complete domain. In partic¬ 
ular, model-based interactive knowledge acquisition tools like MIKADO (Schmidt, 1994; 
Schmidt & Zickwolff, 1992) can make such a complete modeling task much more feasible. 
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Figure 11: Abstracting and Refining an Example Case 


8.4 Abstracting and Refining a Process Planning Case 

We now explain how the example case shown in Figure 9 can be abstracted and how 
this abstract case can be reused to solve a different planning problem. This process is 
demonstrated in Figure 11. The top of this figure shows the concrete planning case C\ 
already presented in Figure 9. This case is abstracted by the Pass algorithm presented in 
Section 6. The algorithm returns 6 different abstract cases^®. One of these abstract cases 
is shown in the center of the figure. The abstract solution plan consists of a sequence of 6 
abstract operators. The sequence of the operators in the plan is indicated by the Roman 
numerals. The particular abstraction is indicated between the concrete and the abstract case 
and denotes which sequence of concrete operators is turned into which abstract operator. 

16. The other 5 abstract cases differ from the shown abstract case in two aspects: In the shown abstract 
solution the additional abstract step seCfixation(none) can be inserted between the steps II and III. The 
abstract step V can also be replaced by the abstract step process^ready, or the abstract steps IV and V 
together can be replaced by the abstract step process^ready. 
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The learned abstract case can now be used to solve the new problem whose initial and 
final concrete states are shown in the bottom of the figure. Even if the concrete workpiece 
looks quite different from the workpiece in case C\ the abstract case can be used to solve 
the problem. The reason for this is that the new workpiece also requires that the left and 
right side must be processed. In particular the right side must also be processed before 
the left side is processed because the left side contains two small grooves which prevent the 
workpiece from being be chucked at that side after it is processed. However, we can see that 
most abstract operators (in particular the operators II, VI, and V) are refined to completely 
different sequences of concrete operators than those from which they were abstracted. 

As already mentioned, the abstract operators used are not independently refinable but 
only mostly independently refinable. Consequently, it can happen that an applicable ab¬ 
stract case cannot be refined. Figure 12 shows an example of a concrete planning problem 
for which the abstract case shown in Figure If is applicable but not refinable. The reason 
for this is the location of the small abstract part at the left side of the workpiece. This small 
part consists of the concrete grid area (1,3) in which raw material must be removed. How¬ 
ever, in this specific situation, this small part must be removed before the large parts, the 
left side of the workpiece contains (the grid areas (2,3), (3,3), and (2,2)), can be removed. 
The reason for this is that without removing this small part, the larger parts located right 
of the small part cannot be accessed by any cutting tool that is able to cut the areas (2,3) 
and (3,3). Consequently this problem can only be solved with the plan shown on the right 
side of Figure 12. Unfortunately, this plan is not a refinement of the abstract plan shown in 
Figure If, because this abstract plans requires that the large parts must be removed before 
the small parts are removed. Hence, the refinement of the operator process_rough(left) fails. 
In this situation the problem solver must select a different abstract plan. 

9. Empirical Evaluation and Results 

This section presents the results of an empirical study of Paris in the mechanical engineer¬ 
ing domain already introduced. This evaluation was performed with the fully implemented 
Paris system using only the abstraction abilities of the system. The generalization com¬ 
ponent was switched-off for this purpose. We have designed experiments which allow us 
to judge the performance improvements caused by various abstract cases derived by Pars. 
Furthermore, we have analyzed the average speed-up behavior of the system with respect 
to a large set of randomly selected training and test cases. 

9.1 Planning Cases 

For this empirical evaluation 100 concrete cases have been randomly generated. Each case 
requires about 100-300 sentences to describe the initial or final state, most of which are 
instances of the mat predicate. The length of the solution plans ranges from 6 to 18 
operators. Even if the generated cases only represent simple problems compared to the 
problems a real domain expert needs to solve, the search space required to solve our sample 
problems is already quite large. This is due to the fact that the branching factor b is between 
1.7 and 6.6, depending on the complexity of the problem. Hence, for a 18-step solution the 
complete search space consists of 3.7 • 10^® states. 
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abs_small_parts(left) 
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Solution 

1. chuck(left) 

2. use_tool(right,t2) 

3. cut(4,3) 

4. cut(4,2) 

5. unchuck 

6. chuck(right) 

7. use_tool(left,tl) 

8. cut(l,3) 

9. cut(2,3) 

10. cut(3,3) 

11. use_tool(center, t3) 

12. cut(2,2) 

13. unchuck 


Figure 12: An Example Case in which the refinement of the abstract plan shown in Figure 
11 fails. 


The case generation procedure leads to solutions which are optimal or nearly optimal. 
All solutions which require less than 10 steps are optimal solutions in the sense that they are 
known to be the shortest solution to the problem they solve. All solutions which are longer 
than 10 steps have been manually checked to see whether they contain steps which are 
obviously redundant. Such redundant steps have been removed. Although these solutions 
are not necessarily shortest solutions, they are nevertheless acceptably short. 

9.2 Evaluating Abstraction by Dropping Sentences 

At first we used the recent version of Alpine (Knoblock, 1993) together with Prodigy- 
4 (Blythe et ah, 1992) to check whether abstraction by dropping sentences can improve 
problem solving in our domain represented as described in Section 8. Therefore, we used 
only the concrete problem solving domain as domain theory for Prodigy. Unfortunately, 
for this representation, Alpine was not able to generate an ordered monotonic abstraction 
hierarchy. The reason for this is that Alpine can only distinguish a few different groups of 
literals because only a few different literal names (and argument types) can be used in the 
problem space. For example, Alpine cannot distinguish between the different sentences 
which are described by the mat or the grid_xpos predicate. But this is very important for 
abstraction. We would like to drop those parts of the grid which represent small rectangles 
such as grooves. However, this would require the examination of the measures associated 
with a grid area (as argument) and also the relation to other surrounding grid areas. There¬ 
fore, which sentence to drop (or which criticalities to assign) cannot be decided statically by 
the name of the predicate or the type of the arguments. All hierarchical planners including 
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Prodigy and Alpine are highly dependent on the representation used, in particular if their 
strategy is restricted to dropping sentences (Holte et ah, 1994, 1995). However, there might 
be another representation of our domain for which those hierarchical planners can improve 
performance but we think that our representation is quite ’’natural” for our domain. 

From this first trial we can conclude that the application domain and representation we 
have chosen for the following experiments with Paris really require more than dropping 
sentences to achieve an improvement by abstraction. 

9.3 Evaluating the PARIS Approach 

The first experiment with Paris was designed to evaluate the hypotheses that in our domain 
there is a need (I) for changing the representation language during abstraction, and (II) for 
reusing abstract cases instead of generating abstract solutions from scratch. To test these 
hypotheses we rely on the time for solving the randomly generated problems using different 
modes of the Paris system. 

9.3.1 Experimental Setting 

In this experiment we used the Paris system to solve the 100 problems from the randomly 
generated cases. Thereby the goal of abstraction is to improve the concrete-level problem 
solver, which performs a brute-force search with a depth-first iterative-deepening search 
strategy (Korf, 1985a) as introduced in Section 7.3. The improvement is determined in 
terms of problem solving time required to solve a single problem. Paris is used to solve 
the 100 problems in three different modes: 

• Pure search: The problem solver is used to solve each problem by pure search without 
use of any abstraction. 

• Hierarchical planning: In this mode Paris uses the introduced abstract domain. How¬ 
ever, abstract cases are not recalled from a case library but they are computed auto¬ 
matically by search as in standard hierarchical planning, but using the new abstrac¬ 
tion language. So, the problem solver first tries to search for a solution to the original 
problem at the abstract domain and then tries to refine this solution. During this 
hierarchical problem solving, backtracking between the two levels of abstraction and 
between each subproblem can occur. Thereby, we used hierarchical planning with the 
new abstraction methodology instead of dropping sentences. 

• Reasoning from abstract cases: In this mode we first used Paris to learn all abstract 
cases which come out of the fOO concrete cases. For each problem, all abstract cases 
that exists according to our abstraction methodology are available when one of the 
problems is to be solved. During problem solving we measured the time required for 
solving each problem using every applicable abstract cases. Then, for each problem, 
three abstract cases are determined: a) the best abstract case, i.e., the case which leads 
to the shortest solution time, b) the worst abstract case (longest solution time) which 
is an abstraction of the aspired solution case, and c) the worst applicable abstract 
case is determined. The difference between b) and c) relates to the difference between 
applicable and refinable abstract cases introduced in Section 7.1. An abstract case 
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selected in c) is applicable to the current problem, but might not be an abstraction 
of the case from which the problem is taken. In b) only abstract cases are selected 
which are indeed abstractions of the current problem, i.e., abstract cases which have 
been previously learned from the case from which the problem is taken. These three 
different cases are selected to figure out the impact of case selection (which is not 
addressed in this paper) on the proposed method. 

Although every problem can theoretically be solved by our brute-force search procedure, 
the exponential nature of the search space avoids the solution of complex problems within 
reasonable time. Therefore, a time-bound of 200 CPU seconds on a Sun Sparc-ELC 
computer was introduced in each of the three modes described above. If this limit-bound 
is exceeded the problem remains unsolved. Increasing this time-bound would increase the 
number of solvable problems in each of the three modes. 

9.3.2 Results 

We have determined the solution time for each of the 100 problems in each of the described 
modes. The average solution time as well as the number of problems that could be solved 
within the time limit is shown in Table 7. We have determined these values for reasoning 
from abstract cases separately for each of the three types of abstract cases. The significance 
of the speedup results has be investigated by using a maximally conservative sign test 
(Etzioni & Etzioni, 1994). Unfortunately it turned out that the speedup of hierarchical 
planning over pure search was not significant. We also couldn’t find a significant speedup 
of reasoning from abstract cases when using always the worst applicable abstract case (c) 
over pure search. This was due to the large number of doubly censored data (both problem 
solvers cannot solve the problem within the time limit), which were counted against the 
speedup hypothesis. However, the improvements of pure search by reasoning from refinable 
abstract cases were significant {p < 0.000001) when using the best refinable case (a) and 
when using the worst refinable case (b). Furthermore, it turned out that the speedup of 
reasoning from refinable cases over hierarchical planning was also significant for an upper 
bound of the p-value of O.OOf. The mentioned p-value is a standard value used in statistical 
hypothesis tests. It is the probability, assuming that the hypothesis does not hold, of 
encountering data that favors the hypothesis as much or more than the observed data in 
the experiment (Etzioni & Etzioni, 1994). Therefore a result is more significant if the 
p-value is smaller. From this analysis, we can clearly see, that our two basic hypotheses 
are supported by our experimental data. Even if not significant we can see a moderate 
improvement in the problem solving time and in the number of solved problems when using 
hierarchical planning with changing the representation language. Please remember that 
hierarchical planning by dropping conditions did not lead to any improvement at all (see 
Section 9.2). Obviously, changing the representation language during abstraction is required 
to improve problem solving in our domain as stated in the first hypothesis (I). 

Very strong support for the second hypothesis (II) can also be found in the presented 
data. We can see significant speedups by reasoning from abstract cases over pure search and 
even over hierarchical planning. Only if the worst abstract case is used for each problem 
to be solved, the speedup is not significant and the problem solving behavior is slightly 
worse than in hierarchical planning. Please note that this situations is extremely unlikely 
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Problem solving mode 

Average solution time (sec.) 

Solved problems 

Pure search 

156 

29 

Hierarchical planning 

Reasoning from abstract cases 

107 

50 

(a) Best refinable case 

35 

94 

(b) Worst refinable case 

63 

79 

(c) Worst applicable case 

II7 

45 


Table 7: Comparison of the average solution time per problem and the number of solved 
problems within a time-bound of 200 seconds. The table compares pure search 
(depth-first iterative deepening), hierarchical planning using the abstract prob¬ 
lem solving domain, and reasoning from abstract cases with differently selected 
abstract cases. 


to happen at all. With a sophisticated indexing and retrieval of abstract cases this situation 
can be avoided for the most part. 

9.4 Evaluating the Impact of Different Training Sets 

In one respect the previous experiment is based on a very optimistic assumption. We always 
assume that all abstract cases required for solving a problem have been learned in advance. 
This situation is not a realistic scenario for an application. Usually, one set of cases is 
available for training the system while a different set of problems needs to be solved. So 
we cannot assume that good applicable abstract cases are always available to solve a new 
problem. Furthermore, the presented example also shows that the problem solving time can 
vary a lot if different abstract cases are selected during problem solving. Therefore, we have 
designed a new experiment to evaluate the improvements caused by the Paris approach in 
a more realistic scenario. 

9.4.1 Experimental Setting 

We have randomly chosen 10 training sets of 5 cases and 10 training sets of 10 cases from 
the 100 available cases. These training sets are selected independently from each other. 
Then, each of the 20 training sets is used for a separate experiment. In each of the 20 
experiments, those of the 100 cases which are not used in the particular training set are 
used to evaluate the performance of the resulting system. Training set and test set are 
completely independent by this procedure. During this problem solving task, we did not 
determine the problem solving behavior for all applicable abstract cases, but we used a 
simple automatic mechanism to retrieve one (hopefully a good) applicable abstract case 
for a problem. Therefore, the cases are organized linearly in the cases base, sorted by the 
length of the abstract plan contained in the case. The case base is sequentially searched 
from longer to shorter plans until an applicable case is found. This heuristic is based on the 
assumption that a longer abstract plan is more specific than a shorter abstract plan and 
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Size of training sets 

Number of abstract cases 


(cases) 

minimum 

maximum 

average 

5 

7 

f5 

9.f 

fO 

8 

25 

f4.2 


Table 8: Comparison of the number of learned abstract cases for a) the fO training sets 
each of which consists of 5 concrete cases and b) the fO training sets each of 
which consists of fO concrete cases. The table shows the minimum, the maximum, 
and the average number of abstract cases learned from the fO training sets of the 
respective size. 


Size of training sets 
(cases) 

Average problem solving time (sec.) 
best set worst set average 

5 

fO 

43 89 59 

35 76 56 


Table 9: Comparison of the problem solving time required for reasoning from abstract cases 
after separate training with a) the fO training sets each of which consists of 5 
concrete cases and b) the fO training sets each of which consists of fO concrete 
cases. The table shows the average problem solving time per problem for the best, 
the worst and the average training set out of the fO training sets of each size. 


divides the actual problem into more, but smaller subproblems. Consequently the longest 
applicable plan should lead to the best improvement. 

9.4.2 Results 

We have statistically evaluated the second experiment. Table 8 shows the number of abstract 
cases which could be learned from the different training sets. The minimum, the maximum 
and the average number of abstract cases that could be learned from the fO training sets of 
the same size is indicated. Note that altogether 42 abstract cases can be learned if all fOO 
cases would have been used for training as in the previous experiment. From the fO training 
sets which contained 5 cases each, between 7 and f5 abstract cases could be learned. As 
expected, if the size of the training set is increased more abstract cases can be learned. 
Table 9 shows the average problem solving time after learning from the different sets. This 
table also shows the minimum, the maximum and the average problem solving time for the 
fO different training sets of the two sizes. We can see that the best training sets leads to 
a problem solving time which is similar or only slightly worse than the optimum shown in 
Table 7. Even in the average case, considerable improvements over the pure search and 
hierarchical problem solving (compare Table 7 and Table 9) can be discovered. The same 
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Size of training sets 
(cases) 

Percentage of Solved Problems 
best set worst set average 

5 

10 

91 68 83 

94 74 86 


Table 10: Comparison of the percentage of solved problems after separate training with 
a) the 10 training sets each of which consists of 5 concrete cases and b) the 10 
training sets each of which consists of 10 concrete cases. The table shows the 
percentage of solved problems for the best, the worst and the average training 
set out of the 10 training sets of each size. 


Size of training sets 
(cases) 

Number of training sets with significant speedups over 
pure search hierarchical planning 

p < 0.0005 p < 0.0005 p < 0.05 

5 

10 

9 4 8 

10 5 7 


Table 11: Comparison of the significance (p-value) of the speedup results over pure search 
and hierarchical planning after separate training with a) the 10 training sets each 
of which consists of 5 concrete cases and b) the 10 training sets each of which 
consists of 10 concrete cases. The table shows the number of training sets which 
cause significant speedups for different p-values. 


positive results can also be identified when looking at the percentage of solved problems, 
shown in Table 10. Here we can also see that for the best training sets the number of solved 
problems is close to the maximum that can be achieved by this approach. Even in the worst 
training set considerably more problems could be solved than by pure search or hierarchical 
planning. 

Additionally all of the above mentioned speedup results were analyzed with the maxi¬ 
mally conservative sign test as described in (Etzioni & Etzioni, 1994). Table 11 summarizes 
the significance results for speeding up pure search and a hierarchical problem solver. It 
turned out that 19 of the 20 training sets lead to highly significant speedups {p < 0.0005) 
over pure search. For this hard upper bound on p-values only about half of the training 
sets lead to significant differences between reasoning from abstract cases and hierarchical 
planning. At a slightly higher upper bound of p < 0.05, about 3/4 of the training sets 
caused a significantly better performance than hierarchical planning. 

Altogether, the reported experiment showed that even a small number of training cases 
(i.e., 5% and 10%) can already lead to strong improvements on problem solving. We can 
see that not all abstract cases must be present, as in the first experiment, to be successful. 
Furthermore, this experiment has shown that even a simple retrieval mechanism (sequential 
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Size of training sets 

(cases) 

Average percentage of solutions with 
shorter/equal/longer solution length 
shorter equal longer 

5 

10 

20 54 26 

22 50 28 


Table 12: Comparison of the length of the solutions created through reasoning from learned 
abstract cases and the solutions available in the concrete cases. The table shows 
the average percentage of solutions with shorter/equal/longer solution length 
after separate training with a) the 10 training sets each of which consists of 5 
concrete cases and b) the 10 training sets each of which consists of 10 concrete 
cases. 


search) can select beneficial abstract cases from the library. Neither of the training situations 
in the second experiment lead to results which are as worse as the worst case shown in Table 

7. 

9.5 Quality of the Produced Solutions 

Although the main purpose of this approach is to improve the performance of a problem 
solver, the quality of the produced solutions is also very important for a practical system. 
The solution length can be used as a very simple criterion to determine the quality of a 
solution. However, in general the quality of a solution should reflect the execution costs 
of a plan, the plans robustness, or certain user preferences (Perez & Carbonell, 1993). 
Because such quality measures are very difficult to assess, in particular in our manufacturing 
domain, we rely on this simple criterion also used for evaluating the quality of solutions in 
Prodigy/Analogy (Veloso, 1992). 

9.5.1 Experimental Setting 

We have analyzed the solutions computed in the previous set of experiments to assess the 
quality of the solutions produced by Paris. Therefore, the length of solutions derived 
during problem solving, after learning from each of the 20 training sets, are compared to 
the length of the nearly optimal solutions contained in the concrete cases. 

9.5.2 Results 

For each training set the length of each solution derived in the corresponding testing phase 
is compared to the length of the solution noted in the concrete case. The percentage of 
solutions with shorter, equal, or longer solution length is determined for each training set 
separately, and the average over the 10 training sets with equal size is determined. Table 
12 shows the result of this evaluation. 

It turned out that there was no big difference in the quality results between the 20 
training sets. In particular, the size of the training sets did not have a strong influence on 
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the results. In Table 12 we can see that between 72% (22% + 50%) and 74% (20% + 54%) 
of the solutions produced are of equal or better quality than the solutions contained in the 
concrete cases. Please note that the concrete cases used for testing are always different 
from the cases used for training. Additionally, the solutions to which we compare the 
results produced by Paris are already nearly optimal solutions due to the case generation 
procedure.Taking this into account, these results are already fairly good. 


9.6 Impact of the Abstract Problem Solving Domain 

The experiments reported before were conducted with the concrete and abstract domain 
representation presented in Section 8 and in Online Appendix 1. In this final experiment 
the impact of the specific choice of an abstract problem solving domain is investigated. 


9.6.1 Experimental Setting 

We created a new abstract problem solving domain which is less constrained than the one 
used before. For this purpose one operator was completely removed and certain conditions 
of the remaining operators were removed also. In particular, the set_fixation operator was 
removed and the conditions abs_chuck_pos, abs_chuckable_wp, and chuck_comp were removed 
from the preconditions of the three remaining operators. Hence, the fact that the chucking 
of a workpiece has an impact on the production plan is now neglected at the abstract level. 
However, the concrete problem solving domain and the generic abstraction theory was not 
modified at all. Consequently, chucking still plays an important role at the concrete level. 
The set of experiments described in Section 9.4 was repeated with the less constrained 
abstract problem solving domain but using the same training and testing sets as before. 


9.6.2 Results 

Table 13 and 14 summarize the results of these experiments. Table 13 shows the average 
problem solving time which occurs after learning from the different training sets. It turns 
out that for all training sets, learning improves the concrete level problem solver, but that 
the speedup is much smaller than when using the original abstract problem solving domain 
(cf. Table 7 and 9). In particular, none of the resulting speedups over concrete level problem 
solving were significant. A similar result can be observed when comparing the percentage 
of solved problems (see Figure 14). There is still a slight improvement in the number of 
problems that could be solved after learning but the improvement is much smaller than 
when using the original abstract problem solving domain (cf. Table 7 and 10). 


17. In all cases up to one, the shorter solutions produced by PARIS are only one step shorter than the solution 
contained in the concrete case. 
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Size of training sets 
(cases) 

Average problem solving time (sec.) 
best set worst set average 

5 

10 

114 118 117 

107 112 110 


Table 13: Using a less constrained abstract problem solving domain: Comparison of the 
problem solving time required for reasoning from abstract cases after separate 
training with a) the 10 training sets each of which consists of 5 concrete cases 
and b) the 10 training sets each of which consists of 10 concrete cases. The table 
shows the average problem solving time per problem for the best, the worst and 
the average training set out of the 10 training sets of each size. 


Size of training sets 
(cases) 

Percentage of Solved Problems 
best set worst set average 

5 

10 

55 52 53 

58 54 56 


Table 14: Using a less constrained abstract problem solving domain: Comparison of the 
percentage of solved problems after separate training with a) the 10 training sets 
each of which consists of 5 concrete cases and b) the 10 training sets each of which 
consists of 10 concrete cases. The table shows the percentage of solved problems 
for the best, the worst and the average training set out of the 10 training sets of 
each size. 


This experiment supported the general intuition that the abstract problem solving do¬ 
main has a significant impact on the improvement in problem solving that can be achieved 
through reasoning from abstract cases. The reason why the less constrained domain leads 
to worse results than the original abstract domain can be explained with respect to the 
criteria explained in Section 7.5. Since important preconditions of the abstract operators 
were removed there are many situations in which the new operators cannot be refined. This 
holds particularly for those situations in which a workpiece cannot be chucked to perform 
the required cutting operations. The new abstract operators are not mostly independently 
refinable. Moreover, since the abstract operator set_fixation is removed the concrete chuck 
and unchuck operator must be introduced during the refinement of the remaining abstract 
operators. Consequently, the goal distance of these abstract operators is increased. These 
two factors are the reason for worse results when using the less constrained abstract domain 
theory. 
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10. Discussion 

In this paper we have shown in detail that in hierarchical problem solving (Sacerdoti, 1974; 
Tenenberg, 1988; Unruh & Rosenbloom, 1989; Yang & Tenenberg, 1990; Knoblock, 1990) 
the limited view of abstraction by dropping sentences as well as the strategy by which 
abstract solutions are computed lead to poor behavior in various relevant situations. This 
observation is supported by comprehensive artificial examples (see Section 2.1 and 2.2) and 
a real-world example from the domain of mechanical engineering (see Section 8), further 
supported by an experiment (see Section 9.2). The recent results reported in (Holte et ah, 
1995) support these observations very well. 

In general, abstraction is the task of transforming a problem or a solution from a con¬ 
crete representation into a different abstract representation, while reducing the level of 
detail (Michalski & Kodratoff, 1990; Giunchiglia & Walsh, 1992; Michalski, 1994). How¬ 
ever, in most hierarchical problem solvers, the much more limited view of abstraction by 
dropping sentences is shown to be the reason why efficient ways of abstracting a problem 
and a solution are impossible (e.g., see Section 2.1 and Figure 4). The second weakness 
of most hierarchical problem solvers is that they usually compute arbitrary abstract solu¬ 
tions and not solutions which have a high chance of being refinable at the next concrete 
level. Although the upward solution property (Tenenberg, 1988) guarantees that a refin¬ 
able abstract solution exists, it is not guaranteed that the problem solver finds this abstract 
solution (e.g., see Section 2.2). Problem solvers are not even heuristically guided towards 
refinable abstract solutions. 

With the Paris approach we present a new formal abstraction methodology for problem 
solving (see Section 5) which allows abstraction by changing the whole representation lan¬ 
guage from concrete to abstract. Together with this formal model, a correct and complete 
learning algorithm for abstracting concrete problem solving cases (see Section 6) is given. 
The abstract solutions determined by this procedure are useful for solving new concrete 
problems, because they have a high chance of being refinable. 

The detailed experimental evaluation with the fully implemented Paris system in the 
domain of mechanical engineering strongly demonstrates that Paris can significantly im¬ 
prove problem solving in situations in which a hierarchical problem solver using dropping 
sentences fails to show an advantage (see Table 7 to If). 

10.1 Related Work 

We now discuss the Paris approach in relation to other relevant work in the field. 

10.1.1 Theory of Abstraction 

Within Giunchiglia and Walsh’s (1992) theory of abstraction, the Paris approach can be 
classified as follows: The formal system of the ground space Si is given by the concrete 
problem solving domain Vc using the situation calculus (Green, 1969) for representation. 
The language of the abstract formal system S 2 is given by the language of the abstract 
problem solving domain Va- However, the operators of are not turned into axioms of 
S 2 . Instead, the abstract cases build the axioms of S 2 . Moreover, the generic abstraction 
theory A defines the abstraction mapping / : Si S 2 . Within this framework, we can view 
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Paris as a system which learns useful axioms of the abstract system, by composing several 
smaller elementary axioms (the operators). However, to prove a formula (the existence of 
a solution) in the abstract system, exactly one axiom (case) is selected. So the deductive 
machinery of the abstract system is restricted with respect to the ground space. Depending 
on the learned abstract cases the abstractions of Paris are either theory decreasing (TD) 
or theory increasing (TI). If the case-base of abstract cases is completely empty then no 
domain axiom is available and the resulting abstractions are consequently TD. If the case- 
base contains the maximally abstract case {{true, true){nop)Y^ (and the generic abstraction 
theory contains the clause —?■ true), then this case can be applied to every concrete problem 
and the resulting abstraction is consequently TI. Even if this maximally abstract case does 
not improve the ground level problem solving, it should be always included into the case-base 
to ensure the TI property, that is not loosing completeness. The case retrieval mechanism 
must however guarantee, that this maximally abstract case is only chosen for refinement if 
no other applicable case is available. Note, that this is fulfilled for the retrieval mechanism 
(sequential search from longer to shorter plans) we used in our experiments. 

10.1.2 Skeletal Plans 

As already mentioned in Section 3.4 the Paris approach is inspired by the idea of skeletal 
plans (Friedland & Iwasaki, 1985). A abstract cases can be seen as a skeletal plan, and 
our learning algorithm is a means to learn skeletal plans automatically out of concrete 
plans. Even if the idea of skeletal plans is intuitively very appealing, to our knowledge, this 
paper contains the first comprehensive experimental support of usefulness of planning with 
skeletal plans. Since we have shown that skeletal plans can be acquired automatically, this 
planning method can be applied more easily. 

For the same purpose, Anderson and Farley (1988) and Kramer and Unger (1992) pro¬ 
posed approaches for plan abstraction which go in the same direction as the Paris algorithm. 
However, this approach automatically forms abstract operators by generalization, mostly 
based on dropping sentences. Moreover, in the abstracted plan, every concrete operator is 
abstracted, so that the number of operators is not reduced during abstraction. Thereby 
this abstraction approach is less powerful than Paris style abstractions. 

10.1.3 Alpine’s Ordered Monotonic Abstraction Hierarchies 

Alpine (Knoblock, 1989, 1990, 1993, 1994) automatically learns hierarchies of abstraction 
spaces from a given domain description or from a domain description together with a plan¬ 
ning problem. As mentioned several times before, Alpine relies on abstraction by dropping 
sentences. However, this enables Alpine to generate abstraction hierarchies automatically. 
For a stronger abstraction framework such as the one we follow in Paris, the automatic 
generation of abstraction hierarchies (or abstract domain descriptions) does not seem to 
be realistic due to the large (infinite) space of possible abstract spaces. To use our power¬ 
ful abstraction methodology, we feel that we have to pay the price of losing the ability to 
automatically construct an abstraction hierarchy. 

Another point is that the specific property of ordered monotonic abstraction hierarchies 
generated by Alpine, allows an efficient plan refinement. During this refinement, an ab- 

18. nop is the ’no operation’ operator which is always applicable and does not change the abstract state. 
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stract plan can be expanded at successively lower levels by msertm^ operators. Furthermore, 
already established conditions of the plan are guaranteed not to be violated anymore dur¬ 
ing refinement. Unfortunately, this kind of refinement cannot be performed for PARls-style 
abstractions. Especially, there is no direct correspondence between the abstract operators 
and concrete operators. Consequently, an abstract plan cannot be extended to become a 
concrete plan. However, the main function of the abstract plan is maintained, namely that 
the original problem is decomposed into several smaller subproblems which causes the main 
reduction in search. 

fO.f.4 Explanation-based Learning, Case-based Reasoning and Analogy 

The presented Paris approach uses experience to improve problem solving, similar to several 
approaches from machine learning, mostly from explanation-based learning (Mitchell et ah, 
f986; DeJong & Mooney, f986), case-based reasoning (Kolodner, f980; Schank, f982; Al- 
thoff & Wess, f992; Kolodner, f993) or analogical problem solving (Carbonell, f986; Veloso 
& Carbonell, f988). The basic ideas behind explanation-based learning and case-based or 
analogical reasoning are very much related. The common goal of these approaches is to 
avoid problem solving from scratch in situations which have already occurred in the past. 
Explanations (i.e., proofs or justifications) are constructed for successful solutions already 
known by the system. In explanation-based approaches, these explanations mostly cover the 
whole problem solving process (Pikes, Hart, & Nilsson, 1972; Mooney, 1988; Kambhampati 
& Kedar, 1994), but can also relate to to problem solving chunks (Rosenbloom & Laird, 
1986; Laird, Rosenbloom, & Newell, 1986) of some smaller size or even to single decisions 
within the problem solving process (Minton, 1988; Minton et ah, 1989). Explanation-based 
approaches generalize the constructed explanations during learning by extensive use of the 
available domain knowledge and store the result in a control rule (Minton, 1988) or schema 
(Mooney & DeJong, 1985). In case-based reasoning systems like Priar (Kambhampati 
& Hendler, 1992) or Prodigy/Analogy (Veloso & Carbonell, 1993; Veloso, 1994) cases 
are usually not explicitly generalized in advance. They are kept fully instantiated in a 
case library, annotated with the created explanations. Unlike cases in Paris which are 
problem-solution-pairs, such cases are complete problem solving episodes containing de¬ 
tailed information of each decision that was taken during problem solving. During problem 
solving, those cases are retrieved which contain explanations applicable to the current prob¬ 
lem (Kambhampati & Hendler, 1992; Veloso & Carbonell, 1993; Veloso, 1994). The detailed 
decisions recorded in these cases are then replayed or modified to become a solution to the 
current problem. All these approaches use some kind of generalization of experience, but 
none of these approaches use the idea of abstraction to speedup problem solving based on 
experience. As already noted in (Michalski & Kodratoff, 1990; Michalski, 1994), abstrac¬ 
tion and generalization must not be confused. While generalization transforms a description 
along a set-superset dimension, abstraction transforms a description along a level-of-detail 
dimension. 

The only exception is given in (Knoblock, Minton, & Etzioni, I99Ia) where Alpine’s 
abstractions are combined with EBL component of Prodigy. Thereby, control rules are 
learned which do not refer to the ground space of problem solving but also to the abstract 
spaces. These control rules speedup problem solving at the abstract level. However, the 
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control rules guide the problem solver at the abstract level so that it finds solutions faster 
and not in a manner that it finds refinable abstract solutions. Although we did not have any 
experience with this kind of integration of abstraction and explanation-based learning, we 
assume that the control rules generated by the EBL component will also guide the problem 
solver towards short abstract solutions which do not cause much reduction in search in 
several circumstances. 

10.2 Requirements and Limitations of PARIS 

In the following, we will summarize again the requirements and limitations of the Paris 
approach. The main requirements are the availability of a good abstract domain description 
and in the availability of concrete cases. 

10.2.1 Abstract Domain 

The most important prerequisite of this method is the availability of the required back¬ 
ground knowledge, namely the concrete world description, the abstract world description, 
and the generic abstraction theory. For the construction of a planning system, the concrete 
world descriptions must be acquired anyway, since they specify the “language “ of the prob¬ 
lem description (essential sentences) and the problem solution (operators). The abstract 
world and the generic abstraction theory must also be acquired. We feel that this is indeed 
the price we have to pay to make planning more tractable in certain practical situations. 

Nevertheless, the formulation of an adequate abstract domain theory is crucial to the 
success of the approach. If those abstract operators are missing which are required to express 
a useful abstract plan, no speedup can be achieved. What we need are mostly independently 
refinable abstract operators. If such operators exist, they can be simply represented in the 
abstract domain using the whole representational power. For hierarchical planning with 
dropping conditions, such an abstract domain must also be implicitly contained in a concrete 
domain in a way that the abstract domain remains, if certain literals of the concrete domain 
are removed (see Section 2.1). We feel that this kind of modeling is very much harder to 
achieve than modeling the abstract view of a domain explicitly in a distinct planning space 
as in Paris. Additionally, the requirement that the abstract domain is given by the user 
has also the advantage that the learned abstract cases are expressed in terms the user is 
familiar with. Thereby, the user can understand an abstract case very easily. This can open 
up the additional opportunity to involve the user in the planning process, for example in 
the selection of an abstract cases she/he favors. 

Research on knowledge acquisition has shown that human experts employ a lot of 
abstract knowledge to cope with the complexity of real-world planning problems. Spe¬ 
cific knowledge acquisition tools have been developed to comfortably acquire such abstract 
knowledge from different sources. Especially, the acquisition of planning operators is ad¬ 
dressed in much detail in (Schmidt & Zickwolff, 1992; Schmidt, 1994). 

10.2.2 Availability of Cases 

As a second prerequisite, the Paris approach needs concrete planning cases (problem- 
solution pairs). In a real-world scenario such cases are usually available in a company’s 
filing cabinet or database. According to this requirement we share the general view from 
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machine learning that the use of this kind of experience is the most promising way to cope 
with highly intractable problems. For the Paris approach the available cases must be 
somehow representative for future problem solving tasks. The known cases must be similar 
enough to the new problems that abstract cases can really be reused. Our experiments 
give strong indications that even a small set of concrete cases for training leads to high 
improvements in problem solving (see Table 9 to ff). 

10.3 Generality of the Achieved Results 

The reported experiments were performed with a specific base-level problem solver which 
performs a depth-first iterative-deepening search strategy (Korf, 1985a). However, we 
strongly believe that the Paris abstractions are also beneficial for other problem solvers 
using backward-chaining, means-end analysis or nonlinear partial-order planning. As shown 
in (Veloso & Blythe, 1994), there is not one optimal planning strategy. Different planning 
strategies usually rely on different commitments during search. Each strategy can be useful 
in one domain but may be worse in others. However, for most search strategies, the length 
of the shortest possible solution usually determines the amount of search which is required. 
In Paris, the whole search problem is decomposed into several subproblems which allow 
short solutions. Consequently, this kind of problem decomposition should be of use for most 
search strategies. 

Moreover, we think that the idea of reasoning from abstract cases, formulated in a 
completely new terminology than the ground space will also be useful for other kinds of 
problem solving such as design or model-based diagnosis. For model-based diagnosis, we 
have developed an approach (Pews & Wess, 1993; Bergmann, Pews, & Wilke, 1994) similar 
to Paris. The domain descriptions consist of a model of a technical system for which a 
diagnosis has to be found. It describes the behavior of each elementary and composed 
component of the system at different levels of abstraction. During model-based diagnosis, 
the behavior of the technical system is simulated and a possible faulty component is searched 
which can cause the observed symptoms. Using abstract cases, this search can be reduced 
and focused onto components which have been already defective (in other similar machines) 
and which are consequently more likely to be defective in new situations. 

10.4 Future Work 

Future research will investigate goal-directed procedures for refinement such as backward- 
directed search or non-linear partial order planners (see Section 7.4). Additionally, more 
experience must be gained with additional domains and different representations of them. 
Furthermore, we will address the development of highly efficient retrieval algorithms for 
abstract cases. As Table 7 shows, the retrieval mechanism has a strong influence on the 
achieved speedup. Even if the linear retrieval we have presented turned out to be pretty 
good, we expect a utility problem (Minton, 1990) to occur when the size of the case- 
base grows. Furthermore, a good selection procedure for abstract cases should also use 
some feedback from the problem solver to evaluate the learned abstract cases based on the 
speedup they cause. This would eliminate unbeneficial cases or abstract operators from the 
case-base or the abstract problem solving domain. Experiments with different indexing and 
retrieval mechanisms have recently indicated that this is possible. 
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Furthermore, the speedup caused by a combination of different approaches such as 
abstraction and explanation-based learning should be addressed. Within the Paris system 
an explanation-based component for case generalization is still present (see Figure 3), but 
was not used for the experiments because the plain abstraction itself had to be evaluated. 
In further experiments, abstraction, explanation-based learning and the integration of both 
has to be addressed comprehensively. This will hopefully lead to a better understanding of 
the different strengths these methods have. 

As a more long-term research goal, PARls-like approaches should be developed and 
evaluated for other kinds of problem solving tasks such as configuration and design or, as 
already started, for model-based diagnosis. 

Appendix A. Proofs 

This section contains the proofs of the various lemma and theorems. 


Lemma 6 (Joining different abstractions) If a concrete domain Vc and two disjoint ab¬ 
stract domains V^i and Va 2 are given, then a joint abstract domain = Pal U Pa 2 can be 
defined as follows: LetVai = (£»!, ^ai, C>ai, Pal) and let Va 2 = (Pa2, ^a2, C>a2, Pa2) • Then 
Va = Pal u Pa2 = (Pal U Ca 2 , Pal U Pa2 , C>ai U Oa 2 , Pal U Pa2) • The joint abstract domain 
Pa fulfills the following property: if Cf is an abstraction of Cf with respect to (Vc, Vai) or 
with respect to (Vc, Va 2 ), then Cf is also an abstraction of Cf with respect to (Pc,Pa)- 

Proof: The proof of this lemma is quite simple. If Cf is an abstraction of Cc with respect 
to [Vc, Vai), then there exists a sequence abstraction mapping a and a sequence abstraction 
mapping /3 as required in Definition 5. As it is easy to see, the same abstraction mappings 
will also lead to the respective case abstraction in (Pc, Pa)- n 


Lemma 7 (Multi-Level Hierarchy) Let (Pq, ... , P/) be an arbitrary multi-level hierarchy 
of domain descriptions. For the two-level description (Vc, Va) with Va = U!/=i and 
Vc = Pq holds that: if Cf is an abstraction of Cf with respect to (Pq, ... , P/) then Cf is 
also an abstraction of Cf with respect to (Vc, Va). 

Proof: Let Cf = {{sq, sf)), o^') be a case in domain Pj, (intermediate state are denoted by 
s)), let Co = ((sQ,s°),d°) be a case in domain Pq (intermediate state are denoted by s)), 
and let Cf be an abstraction of case Cq with respect to (Pq, ... ,Vfi. Then a sequence of 
cases (Cl, ... ,Cj,_i) exists such that Ci is from the domain Vi and Ci+i is an abstraction of 
the case Ci with respect to [Vi, Pi+i) for all i G {0,... ,12— I}. Now we proof by induction 
over n that Cf is also an abstraction of Cq with respect to [Vc, Va) (see figure 13). The basis 
[n = 1) is obvious: C\ is abstraction of Cq with respect to (Pq, Pi) and is consequently also 
an abstraction with respect to [Vc, Va). Now, assume that the lemma holds for any cases up 
to the domain Pj/_i. It follows immediately that Cf-i is an abstraction of Cq with respect 
to [Vc, Va). Let Cf-i = {{s'o, s(), o') and let the intermediate states be denoted by s),. From 
Definition 5 follows, that a state abstraction mapping a and a sequence abstraction mapping 
/3 exists, such that a(s(j^^j) = s), for all r G {0,... , k}. Because Cf is an abstraction of Cf-i 


no 
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Figure 13: Abstraction mappings for hierarchies of abstraction spaces 


with respect to Hj,), it also exists a state abstraction mapping a' and a sequence 

abstraction mapping (i' such that = s'- for all j G {0,... ,m}. Now, we can 

define a state abstraction mapping a"(s) = a'(a(s)) and a sequence abstraction mapping 
(3"{j) = It is easy to see, that a” is a well defined state abstraction mapping 

(s D s' =y a{s) D a(s') a'(a(s)) A a'(a(s'))) and that /3" is a well defined sequence 

abstraction mapping (/3(/3'(0)) = 0; /3(/3'(m)) = /3{k) = ra; n < n O l3'{u) < l3'{v) O 
I3{l3'{u)) < I3{l3'{v))). Furthermore it follows 

leading to the conclusion that Cj, is an abstraction of Cq with respect to [Vc, T>a)- C 


Theorem 8 (Correctness and completeness of the Pass algorithm) If a complete SLD- 
refutation procedure is used in the Pass algorithm, then Case Cf is an abstraction of case Cc 
with respect to {Vc, Va) and the generic theory A, if and only ifCf G PABS((Ilcj C>a, A), CP- 

Proof: 

Correctness (“C”): If Ca is returned by Pass, then ((oj,. .. ,of),a**,f3) G Paths holds 
in phase-IV. We can define a state abstraction mapping a{s) := {e G a**\TZc U d U s h e}, 
which, together with the sequence abstraction mapping /3 will lead to the desired conclusion. 
For every operator o“, we know by construction of phase-IV, that {(3{i — 1), /3(f), o“, t) £ G 
holds. By construction of phase-III, we can conclude that U TZa ^ PrCga holds and 

that consequently r^UT^a 1“ PrCga also holds for the respective execution of the body of the 
while-loop in phase-IV. Since T£ C a' C a** holds and h is a monotonic derivation operator, 
it is obvious that ^(^(((q) UT^a 1“ PrCga. Furthermore, the ‘if for all’-test, which is executed 

o“ 

before the extension of the path, ensures that (sqq_^jna**) —A (sj^q.^fla**) holds. Together 

o“ 

with the fulfillment of the precondition of the operator we have a(sqq_^p —A a(s(jq.p. 
Thus, we have shown, Cf is correct abstraction with respect to Definition 5. 

Completeness (“A”): Assume, case Ca = {{sq, sff), [o^,... ,off)) is an abstraction of Cc 
based on a deductively justified state abstraction mapping. Then there exists a state ab- 

19. Note that a** refers to the set hnally constructed after termination of the while-loop. We use a* to 
denote the respective set during the construction in this loop. 
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straction mapping a and a sequence abstraction mapping /3 such that 

holds for alH G {1,... , m}. Since a is deductively justified by A, it follows by construction 
of phase-II, that C Since h is a monotonic derivation operator, the precondi- 

ton of o“ is also fulfilled in Furthermore, the addlist of the operator is fulfilled in 

consequently also fulfilled in s“. By the construction of phase-III, it is now 
guaranteed, that {(3{i — f),/3(i), o“, r) G G. Now, we would like to show, that in phase-IV: 

• there exists a sequence of assignments to the variable Paths, such that ((),/3o,ao) ^ 
Paths, ((oj), /3i, a\) G Paths, ..., ((oj,... , o%),[3.rm cim) ^ Paths , 

• /3fc(z/) = /3(z/) for z/ G {0,... , k} 

• (a^ n sf) C a(sf) for I G {f ,... ,n} and 

• 5 [fi=iAddo-. 

The proof is by induction on i. The induction basis is obvious due to the initialization 
of the Paths variable. Now, assume that ((oj,... ,o^),/3fc,ap G Paths (with k < m) 
at some state of the execution of phase-IV. Since, [3[k + l),o^_l_^,r) G G holds as 

argued before, and [i{k:) = (3k{k) by induction hypothesis, the selected operator sequence 
is tried to be extended by o“ = in the body of the while-loop. Additionally, we 

know, that T£ contains exactly those sentences which are required to proof the precondition 
of (^k+i- Note, that since the SLD-resolution procedure is assumed to be complete and 
is applicable in a(s^), T£ is required to proof the preconditition of o“ if and only if 
T£ C Since a is deductively justified, Ve G T£,\fl G {f,... , m} holds: e G 

if U TZc U Ah e. By construction of the sf,\fe £ T£,\fl £ {I,... , m} holds: e £ Oi{syy-^) 
if e G sf. Consequently, T£ f] sf C a{sf) for all I £ {I,... ,m}. On the other hand, we 
also know that leads to Consequently, Addo-^^^ C Following 

the same argumentation as above, we can conclude that [Addo'^ ^ H sf) C a{sf) for all 
I £ {I,... , m}. Consequently, for a' = afyj T£ yj Addg"^^^ holds that a' £] sf C a{sf). Now, 

o“ 

we can conclude that Paths is extended by of_^^ as follows. Since a 

holds and that Addga £ a' and [a' fl V a[sf^^^-^), we can immediately follow that 

(a n —A (a Consequently, ((oi ,... ,Oj,, , (ik+i) h Paths with 

= a' and f3k+i{v) = /3fc(zz) = f3{p) for p £ {l,...,k} and f3k+i{k + 1) = fi{k). So, 
the induction hypothesis is fulfilled for k + 1. Thereby, it is shown that Ga is returned by 
Pass. □ 
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